Talk:EclipseLink/Development/JPA2.0/Extended Map support/MappedKeyMapContainerPolicy

Some comments

• 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

New API

• 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)