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.
Difference between revisions of "EclipseLink/Development/JPA2.0/derived ids"
m (→Issue Summary) |
(→General Solution) |
||
| Line 8: | Line 8: | ||
==General Solution== | ==General Solution== | ||
| − | Mapping PK to relationship mappings is | + | 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== | ==Work Required== | ||
Revision as of 14:04, 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
- Develop model for testing
- approx 4 days - should include all permutations of PK combinations. (ie derived IdClass in EmbeddedId)
- 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