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.
Talk:EclipseLink/Development/JPA2.0/Extended Map support/MappedKeyMapContainerPolicy
< Talk:EclipseLink/Development/JPA2.0/Extended Map support
Revision as of 10:47, 19 November 2008 by Tom.ware.oracle.com (Talk | contribs) (→Reply to initial comments: new section)
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.
- 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
- 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.
- Why would it be in ForeignReferenceMapping instead of CollectionMapping?
- I would like to build the ChangeRecord properly, but have not fully investigated
- Updated the document with current information about how data is read