Because EDC allows Studio and Server to dynamically query an external database during Rulesheet/Decision Service execution, the Vocabulary must contain the necessary key and identity information to allow Studio and Server to access the specific data required. There are two identity types which may be selected for each Vocabulary entity: application and datastore.
Application Identity
With application identity, the field(s) of a given table’s primary key are present as attributes of the Vocabulary entity. As a result, application identity normally means that the table’s primary key field(s) have some business meaning themselves; otherwise they wouldn’t be part of the Vocabulary. The Cargo sample (described in the Basic Rule Modeling and Using EDC tutorials) illustrate entities using application identities. In the case of entity Aircraft, the unique identifier (primary key) is tailNumber. In the database metadata, tailNumber is the designated primary key field. The presence in the Vocabulary of a matching attribute named tailNumber informs the auto-mapper that this particular entity must be application identity.
Datastore Identity
A Vocabulary entity uses datastore identity when it does not have an attribute that matches the database table’s primary key field(s) . The table’s primary key is effectively a surrogate key which really has no business meaning. If the designated primary key fields in the imported database metadata are not present as attributes in the Vocabulary entity, then the Vocabulary Editor will assume datastore identity and insert the table’s primary key field(s) in the datastore-identity:column property.
We have modified our Aircraft table slightly to change the primary key. Previously, we assumed that tailNumber was the unique identifier for each Aircraft record – in other words, every aircraft must have a tail number and no two can have the same one. Let’s assume now that this is no longer the case – perhaps tailNumber is optional (perhaps aircraft based in some countries don’t require one?) or we somehow acquired two aircraft with the same tailNumber. So instead of tailNumber, we adopt a surrogate key for this table named Aircraft_ID that will always be non-null and unique. And since this field has no real business meaning (and we never expect to write rules with it), it isn’t included in the Vocabulary.
Note: We can get to this state by clearing the database metadata, and then -- in the database - clearing (or deleting/recreating) the database. When we create the database schema again, the entity identities are all defaulted to datastore identities.
When the auto-mapper updated the schema, the Entity Identity was set to a NULL, and set the primary key field(s) in Identity Column Name as Aircraft_ID, as shown:
Figure 306. Automatic Mapping of Datastore Identity Column
If the auto-mapper does not detect the correct primary key in the metadata, we may need to manually select the field from the drop-down list, as shown:
Figure 307. Manual Mapping of Datastore Identity Column
By choosing datastore identity we are delegating the process of identity generation to the JDO implementation. This does not mean that we cannot control how it does this. The Vocabulary Editor offers the following ways to generate the identities:
Native - Lets Hibernate choose the appropriate method for the underlying database. This usually means a Sequence in the RDBMS. Depending on the RDBMS you use, a sequence may require the addition of a sequence object or generator in the database.
Table - Uses a table in the datastore with one row per table, storing the latest max id.
Identity - Uses identity (Requires identity support in the underlying database.)
Sequence - Uses sequence (Requires sequence support in the underlying database.)
UUID - A UUID-style hexadecimal identity.
All of these strategies are database-neutral except for sequence. It is generally recommended that identity strategy be adopted for Vocabularies that are used to generate the database. When mapping to an existing database either identity or sequence strategies are typically used, depending on the database design.
These generators can be used for both datastore and application identities. The datastore identity is always using a strategy; if not explicitly set by the user, a default strategy is used. The application identity does not have a default strategy.
All strategies are using the integer data type with the exception of UUID which is using a string data type. If the type of the application identity attribute type does not fit the selected value strategy (for application identity), you get an alert.
Native - Lets Hibernate choose the appropriate method for the underlying database. This usually means a Sequence in the RDBMS. Depending on the RDBMS you use, a sequence may require the addition of a sequence object or generator in the database.