JDO : Compound Identity Relationships

An identifying relationship (or "compound identity relationship" in JDO) is a relationship between two
objects of two classes in which the child object must coexist with the parent object and where the primary
key of the child includes the PersistenceCapable object of the parent. So effectively the key aspect of this
type of relationship is that the primary key of one of the classes includes a PersistenceCapable field
(hence why is is referred to as Compound Identity). This type of relation is available in the following
forms

1-1 Relationship

Lets take the same classes as we have in the 1-1 Relationships.
In the 1-1 relationships guide we note that in the datastore representation of the User and
Account the ACCOUNT table has a primary key as well as a foreign-key to USER.
In our example here we want to just have a primary key that is also a foreign-key to USER.
To do this we need to modify the classes slightly and add primary-key fields and use
"application-identity".

In addition we need to define primary key classes for our User and Account classes

In the child Primary Key class, you must have a field with the same name as the relationship in the
child class, and the field in the child Primary Key class must be the same type as the Primary Key
class of the parent

You can only have one "Account" object linked to a particular "User" object since the FK to the "User"
is now the primary key of "Account". To remove this restriction you could also add a "long id" to
"Account" and make the "Account.PK" a composite primary-key

1-N Collection Relationship

Lets take the same classes as we have in the 1-N Relationships
(FK). In the 1-N relationships guide we note that in the datastore representation of the
Account and Address classes the ADDRESS table has a primary key as well as a
foreign-key to ACCOUNT. In our example here we want to have the primary-key to ACCOUNT to
include the foreign-key. To do this we need to modify the classes slightly, adding primary-key
fields to both classes, and use "application-identity" for both.

In addition we need to define primary key classes for our Account and Address classes

In the child Primary Key class, you must have a field with the same name as the relationship in the
child class, and the field in the child Primary Key class must be the same type as the Primary Key
class of the parent

If we had omitted the "id" field from "Address" it would have only been possible to have one "Address"
in the "Account" "addresses" collection due to PK constraints. For that reason we have the "id" field
too.

1-N Map Relationship

Lets take the same classes as we have in the 1-N Relationships
(FK). In this guide we note that in the datastore representation of the Account and
Address classes the ADDRESS table has a primary key as well as a foreign-key to
ACCOUNT. In our example here we want to have the primary-key to ACCOUNT to
include the foreign-key. To do this we need to modify the classes slightly, adding primary-key
fields to both classes, and use "application-identity" for both.

In addition we need to define primary key classes for our Account and Address classes

In the child Primary Key class, you must have a field with the same name as the relationship in the
child class, and the field in the child Primary Key class must be the same type as the Primary Key
class of the parent

If we had omitted the "alias" field from "Address" it would have only been possible to have one
"Address" in the "Account" "addresses" collection due to PK constraints. For that reason we have the
"alias" field too as part of the PK.