MappedById Support

Issue Summary

In JPA 1.0 primary key columns could only be mapped to @Basic attributes. Primary Keys that were derived from Foreign Keys had to be mapped twice, once as the relationship mapping and again as an @Basic. JPA 2.0 adds the functionality to designate a Relationship as providing the primary key for an Entity, see | DerivedId . When using an embeddedid, a @MappedById annotation can be used on a relationship mapping to indicate that it uses the same Id field that is also defined by the target ID field in the Embeddedid.

See JPA 2.0 section 2.4.1 for details.

General Solution

The EmbeddedID will be difficult to support as values in the EmbeddedID will need to be populated by EclipseLink on persist(), merge() calls even though they are not the sources of Identity for the Entity. Even more complicated if the derived ID is an IdClass then an instance of that class must be stored in the EmbeddedId which will be new functionality in EclipseLink. Transformation Mapping may be leveraged in combination with the CMP3Policy to support this functionality.

Metadata processing

The metadata processing will need a number of changes to support the notion of id classes and embedded id classes within their own embedded id's. The spec provided 6 examples, so we'll work through each and discuss the metadata processing behevior and any changes needed to it.

The first required change will be that we will create a new DerivedIdClassAccessor mapping. This accessor will be built for those cases where and EmbeddedId class maps to a either a derived IdClass or EmbeddedId class of the parent entity. Previously only, BasicAccessors were allowed on an embedded id class. We will now support both BasicAccessors and DerivedIdClassAccessors. The new DerivedIdClassAccessor will extend the existing EmbeddedAccessor, essentially creating one level of nested embedded mappings for the primary key class of the dependent entity.

All the mappings from the DerivedIdClassAccessor will be added to the owning descriptor's primary key list (and will also be used as the foreign key association from the dependant entity to the parent entity).

Example 1

The parent entity has a simple primary key and the dependent entity uses EmbeddedId to represent a composite key.

Example 4

The parent entity has a simple primary key and the dependent's primary key consists of a single attribute corresponding to the simple primary key of the parent entity. The dependent entity has a primary key attribute in addition to the relationship attribute corresponding to the primary key. This attribute is mapped to the primary key by the mappedById annotation applied to the relationship.

Example 5

The parent entity uses IdClass. The dependent's primary key class is of the same type as that of the parent entity and the dependent entity uses the EmbeddedId and MappedById annotations. The IdClass either needs to be annotated Embeddable or denoted as an embeddable class in the XML descriptor.