5.6 Identity

An instance is identified uniquely in the datastore via an identity value. JDO has two durable types of identity: datastore and application. With both types, the identity value is stored in one or more columns of the class's table. Those columns become the table's primary key.

For example, we use datastore identity for the Movie class defined in the com.mediamania.content package. The JDO implementation may represent datastore identity as an INTEGER in the relational schema. Line [1] of Example 5-1 illustrates the use of the oid column to store the datastore identity value for the Movie table, which is defined as the table's primary key on line [2] .

Example 5-1. Datastore identity stored in a primary-key column

 CREATE TABLE Movie (     oid         INTEGER  [1]  title       VARCHAR(24),     rating      CHAR(4),     genres      CHAR(16),     PRIMARY KEY(oid)  [2]  ) 

Each implementation has its own default name for this column, but you can usually specify the name that should be used.

You may have a table with no primary key defined, but instead have a unique index defined for one or more columns. With either a primary key or a unique index, the associated columns are used for storing the identity value. If you use a unique index for a JDO identity, none of the columns in the index can have a null value.

With datastore identity, either the JDO implementation or the datastore itself provides a unique identity value for each instance. The datastore identity value is separate from the fields you define in your class. The representation of the datastore identity is managed entirely by the JDO implementation.

Some databases automatically generate primary keys when rows are inserted into a table. These columns typically use a special sequence type. Essentially, they are read-only columns whose values cannot be changed when they are under application control. Some JDO implementations may allow you to map datastore identity to use these columns.

With application identity, you specify one or more Java fields in a class to be the primary-key fields . These fields are mapped onto the columns that serve as the primary key of the class's table. When using application identity you must specify which fields in the class are primary-key fields and define an application-identity class.

Chapter 10 covers identity in detail, but feel free to examine this chapter if you would like more on this now. An understanding of identity does not require any material in the intervening chapters. If you are trying to implement a JDO application as you read this book, and you are using an existing relational database schema that has defined primary keys, you may want to jump ahead and read Chapter 10. Otherwise, just assume while reading this chapter that your table contains one or more columns that serve as identity columns , and that they correspond to some specific fields in your class.

JDO implementations often use a unique number to provide a datastore-identity value. These numbers are often generated by a sequence facility. Your application may use a sequence generator in your existing relational schemas to provide unique values for a primary key. Some JDO implementations allow you to identify a specific sequence in the datastore to use for obtaining unique identity values for datastore identity. This sequence is often specified in the metadata using a vendor-specific extension element. Currently, applications cannot directly access such a sequence generator to assist in generating unique values for application identity using a standard JDO syntax. However, some JDO implementations provide facilities for generating unique values for your application-identity classes. If you are using application identity and do not have a real-world identifier that defines the identify for a particular instance, you will need to use an interface provided by the JDO implementation or datastore to obtain unique values. Such a facility is being considered for a future JDO release.