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/JPA 2.0/nested embedding"

m (Test Model)
m (Nested Embedding)
Line 8: Line 8:
 
The following are new requirements introduced in the JPA 2.0 specification
 
The following are new requirements introduced in the JPA 2.0 specification
 
*R1: An embeddable class may be used to represent the state of another embeddable class.  
 
*R1: An embeddable class may be used to represent the state of another embeddable class.  
*R2: An embeddable class (including an embeddable class within another embeddable class) may contain a collection of a basic type or other embeddable class.[17]
+
*R2: An embeddable class (including an embeddable class within another embeddable class) may contain a collection of a basic type or other embeddable class.
 +
**''I interpret this to mean that embeddables can contain a collection of embeddables
 
*R3: Direct or indirect circular containment dependencies among embeddable classes are not permitted.
 
*R3: Direct or indirect circular containment dependencies among embeddable classes are not permitted.
 
*R4.0: An embeddable class may contain a relationship to an entity or collection of entities.  
 
*R4.0: An embeddable class may contain a relationship to an entity or collection of entities.  
Line 31: Line 32:
 
The embeddable classes Vitals, TeamVitals and PersonalVitals are bound to their owning Entity (HockeyPlayer) and are not sharable in HockeyTeam or Role.
 
The embeddable classes Vitals, TeamVitals and PersonalVitals are bound to their owning Entity (HockeyPlayer) and are not sharable in HockeyTeam or Role.
  
Requirements represented:
+
====Requirements represented:====
*
+
Requirements not represented yet:
+
  
 +
*R1 - verify: entity state representation by composition (not aggregation)
 +
**(Vitals-->TeamVitals)
 +
*R4.0 - Embeddable has relationship to a collection of entities
 +
**(TeamVitals-->Role)
 +
*R4.0 - Embeddable has relationship to an entity
 +
**(TeamVitals-->HockeyTeam)
 +
 +
====Requirements not represented yet:====
 
This model will need to be extended to exercise the following requirements.
 
This model will need to be extended to exercise the following requirements.
 
*R2 - Embeddable contains a collection of basic types
 
*R2 - Embeddable contains a collection of basic types
 
*R3 - A variant case to exclude circular references
 
*R3 - A variant case to exclude circular references
*R4
+
*R4.1 - we need another root parallel to HockyPlayer that has it's own embeddables so that we can link TeamVitals to the containing entity of the other embeddable
 +
*R4.2 - we need an embedded Id that has a R4.1 link (variant) and one that does not
  
 
[[Image:Nested_embeddable_uml_class.gif]]
 
[[Image:Nested_embeddable_uml_class.gif]]

Revision as of 15:38, 24 September 2008

Nested Embedding

JPA 2.0 Root | Enhancement Request

References

Requirements

The following are new requirements introduced in the JPA 2.0 specification

  • R1: An embeddable class may be used to represent the state of another embeddable class.
  • R2: An embeddable class (including an embeddable class within another embeddable class) may contain a collection of a basic type or other embeddable class.
    • I interpret this to mean that embeddables can contain a collection of embeddables
  • R3: Direct or indirect circular containment dependencies among embeddable classes are not permitted.
  • R4.0: An embeddable class may contain a relationship to an entity or collection of entities.
  • R4.1: Since instances of embeddable classes themselves have no persistent identity, the relationship from the referenced entity is to the entity which contains the embeddable instance(s) and not to the embeddable itself.[18]
  • R4.2: An embeddable class that is used as an embedded id or as a map key must not contain such a relationship.

Issue Summary

  • I1: Access type for an embeddable is determined by the entity or the embeddable in which it is embedded - see 2.5 of the spec.

General Solution

Analysis

  • In the JPA 2.0 specification, the following changes to the description of embeddable classes are made.
    • Collections of embeddables are supported
    • @EmbeddedId annotation is used when the the composite primary key of an entity or mapped superclass is an embeddable


Design

Test Model

The following test model from eclipselink.jpa.test/org.eclipse.persistence.testing.models.jpa.complexaggregate.HockeyTeam will be used. The embeddable classes Vitals, TeamVitals and PersonalVitals are bound to their owning Entity (HockeyPlayer) and are not sharable in HockeyTeam or Role.

Requirements represented:

  • R1 - verify: entity state representation by composition (not aggregation)
    • (Vitals-->TeamVitals)
  • R4.0 - Embeddable has relationship to a collection of entities
    • (TeamVitals-->Role)
  • R4.0 - Embeddable has relationship to an entity
    • (TeamVitals-->HockeyTeam)

Requirements not represented yet:

This model will need to be extended to exercise the following requirements.

  • R2 - Embeddable contains a collection of basic types
  • R3 - A variant case to exclude circular references
  • R4.1 - we need another root parallel to HockyPlayer that has it's own embeddables so that we can link TeamVitals to the containing entity of the other embeddable
  • R4.2 - we need an embedded Id that has a R4.1 link (variant) and one that does not

Nested embeddable uml class.gif

Implementation

Work Required

  • For all tests verify that both JPA and ORM implementations adhere to the JPA 2.0 specification
  • Extend test model in eclipselink.jpa.test
  • Add model that includes an @EmbeddedId embedded composite primary key

Back to the top