Talk:EclipseLink/Development/JPA2.0/Extended Map support/MappedKeyMapContainerPolicy
< Talk:EclipseLink/Development/JPA2.0/Extended Map support(Redirected from Talk:EclipseLink/Development/JPA2.0/Extended Map support/CollectionTableMapMapping)
- I updated some typos, added "Supported Features" sections and some open issues.
- The doc should include the JPA annotations and XML defined for this mapping.
- How will the attribute accessors on the nested mappings be used, or what aspects of the nested mappings will be used?
- What is the public API for this new mapping? There should be an API sections that defines this.
- The name seems odd, perhaps just MapMapping, or use the JPA name, CollectionOfElementsMapping, or ElementMapMapping.
- Is a new ChangeRecord created for this mapping, how does it determine what changed?
- Is a new mapping the best design for this, what are the pros/cons over creating a MapPolicy in ForeignReferenceMapping? It seems like a lot of complex things that are done in AggregateCollectionMapping and UnidirectionalOneToManyMapping may require duplication.
- Will this mapping use the old commit like AggregateCollectionMapping, or build its ChangeRecord correctly?
- If the keys are Entities (and possibly values) how will the data be read, a single query or n+1 queries?
- James.sutherland.oracle.com 16:23, 17 November 2008 (UTC)
Reply to initial comments
- I will add a public API section and a brief overview of the JPA configuration
- Added information about attribute accessors
- At the moment, the plan for this mapping is to have it only represent Maps that store some of their information in a RelationTable and to deal with map mappings that do not do that in a different way. That is the reason it is not simply MapMapping. I am open to other names. (See http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/Extended_Map_support)
- I am still working on how the change records work. For the very simple functionality I have tried so far, I am using the same mechanism as we use for CollectionMappings with a MapContainerPolicy. I suspect this will change.
- I am not clear how what you mean by MapPolicy
- Basically a new MapPolicy on CollectionMapping, the MapPolicy could have the keyMapping, and the CollectionMapping itself is responsible for writing the value.
- The basic advantage is that hopefully the writing of the target can be reused, although this may turn out to be more trouble than its worth.
- The main reasoning is that AggregateColectionMapping, DirectCollectionMapping, UnidirectionOneToManyMapping do some complex stuff,
- and it would seem that this would have to be duplicated in a CollectionTableMapMapping.
- James.sutherland.oracle.com 15:05, 19 November 2008 (UTC)
- Are you talking about a type of MapContainerPolicy with additional functionality or some other kind of MapPolicy
- Assuming there was a MapPolicy, what actual mappings would be used for various mappings? Below are some examples that are unclear to me.
- Anything with an Entity key. (Entity -> Field, Entity -> Embeddable, Entity -> Entity)
- Anything with an Aggregate key.
- The MapPolicy key Mapping could be Direct, AggregateObject, OneToOne, the value would be determined by the CollectionMapping, basic->DirectCollection, embedded->AggregateCollection, Entity with foreign key -> OneToMany or UnidirectionalOneToMany, Entity with join table -> ManyToMany.
- James.sutherland.oracle.com 15:06, 19 November 2008 (UTC)
- Why would it be in ForeignReferenceMapping instead of CollectionMapping?
- Your right, only CollectionMapping - James.sutherland.oracle.com 15:05, 19 November 2008 (UTC)
- I would like to build the ChangeRecord properly, but have not fully investigated
- Updated the document with current information about how data is read
- The new API looks good, I assume that setting the keyTable on the MapKey and the valueMapping on the container policy are not required as initialize should be able to do this.
- James.sutherland.oracle.com 21:33, 15 December 2008 (UTC)