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) |
(→Issue Summary) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
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. | 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. | + | See JPA 2.0 section 2.4.1 for details. This feature does not include the new "MappedByID" annotation; this will be handled as a seperate feature |
==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, the JPA PK class can be different than EclipseLink's internal representation of the PK (which is just a collection with values pulled from the object using the writable pk mappings). In order 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. This is done lazily the first time a find method is called | ||
| + | |||
| + | 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. This is in addition to defining a CMP3Policy and setting the primary key class to be used for JPA in the case of a composite primary key. | ||
==Work Required== | ==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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 14:14, 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.4.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, the JPA PK class can be different than EclipseLink's internal representation of the PK (which is just a collection with values pulled from the object using the writable pk mappings). In order 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. This is done lazily the first time a find method is called
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. This is in addition to defining a CMP3Policy and setting the primary key class to be used for JPA in the case of a composite primary key.
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.