Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/JPA2.0/derived ids"

(General Solution)
(Work Required)
Line 15: Line 15:
  
 
==Work Required==
 
==Work Required==
# Develop model for testing
+
None, feature is complete. 
#: approx 4 days - should include all permutations of PK combinations.  (ie derived IdClass in EmbeddedId)
+
See the PartnerLink class in the JPA Advanced test model for a simple example using a derived id, and the JPA advanced.derivedid test model for a more complex example.
# Update Processing
+
#: approx 5 days - processing @Id placement
+
#: approx 4 days - processing @MappedById and support populating EmbeddedIds
+
#: approx 3 days - processing derived IdClass in EmbeddedId
+
#: approx 1 day - processing XML
+

Revision as of 14:07, 25 March 2009

Derived Identifiers

JPA 2.0 Root | Enhancement Request

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. Once a relationship is marked as being an ID the PK of that Entity becomes (or includes in the case of composite PK) the ID of the target entity; a derived ID.

See JPA 2.0 section 2.1.3.1 for details. This feature does not include the new "MappedByID" annotation; this will be handled as a seperate feature

General Solution

Mapping PK to relationship mappings is supported in EclipseLink Native API because EclipseLink only requires that an ID field have a writable mapping, and use a collection of ID values (as pulled from the writable mapping) as the primary key already. This means that EclipseLink could already be using OneToOne mappings as the ID field in its internal PK representation even though the JPA tags identified a basic mapping with @ID - if the basic mapping was also marked as insertable/writable=false.

The find method is really the only place a JPA PK class is required. Unfortunately, this can be different than EclipseLink's internal representation of the PK (a collection with values as pulled from the writable pk mappings). Inorder to conciliate the two differing Key representations, EclipseLink mapping objects now have an isIDMapping flag used to indicate a user has marked a mapping as part of the Entity's primary key. The CMP3Policy then grabs all mappings with this flag set inorder to pull out the fields in the primary key class that is passed in to the find method.

Setting this flag manually using the setIsIDMapping Mapping method will be required for using the EntityManager find method with Entities that have been defined exclusively through Native EclipseLink projects/descriptor api.

Work Required

None, feature is complete. See the PartnerLink class in the JPA Advanced test model for a simple example using a derived id, and the JPA advanced.derivedid test model for a more complex example.

Back to the top