Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Updated Design for JPA 2.0 Map Collection Features

Hi Doug,

The plan is to have JPA configuration (orm.xml, annotations, and eclipselink-orm.xml) work exactly as it is specified in the JPA 2.0 specification. There will be a brief section in the design document about this, but since there are no changes from the spec, it will not be a full cut-and-paste of what the spec says about these kinds of mappings. The initial plan does not include any eclipselink-specific functionality (i.e. configuration that would only be available in eclipselink-orm.xml)

The open issues section is in the second doc. Please feel free to add items to this section you are concerned about or to mention them on the "Talk" page.


  As for mutation of keys:

For entities, my assumption at the moment is that the hashcode is associated with the identity of the Entity and therefore mutation that affects the hashcode is not allowed.

  The spec says the following for aggregates:

"Note that when an embeddable instance is used as a may key, these attributes (the attributes used in hashcode and equals) represent its identity. Changes to embeddable instances used as map keys have undefined behaviour and should be avoided."

I will add any validation that is possible without weaving. I consider weaving-enabled validation of this kind to be a separate feature - one that could be added as an enhancement request and scheduled as time permits.


Douglas Clarke wrote:

The native API examples look fine to me. I am very interested in seeing the annotations, orm.xml, and eclipselink-orm.xml changes that will accompany this work.

I also noticed at the top of the second page you listed goals. Can I assume since no limitations or open issues section exists in here that all of these are attainable in your design? If we do not list any limitations of the use of this feature consumers will assume its compatible with all other features. Just want to make sure that is the plan.

In general I am always concerned about mappings using Maps where a change in the target or in this case a complex key object would 'break' the key-value relationship. Is there any support for handling this? If I use an entity as the key in a relationship then I assume my hashCode method on my entity should be immutable. Do we do anything to enforce that or handle the case where the state of entity changes and violates this?


-----Original Message-----
From: Tom Ware Sent: Monday, December 15, 2008 2:48 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Updated Design for JPA 2.0 Map Collection

Hi All,

The following two wiki pages have been updated to reflect an altered high-level design. Please provide comments ASAP, especially about the sections on public API. The goal is to check-in the public API framework soon to allow parallel work on the JPA configuration for the features and on the actual features.

eclipselink-dev mailing list
eclipselink-dev mailing list

Back to the top