[
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.
(http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/Extended_Map_support/MappedKeyMapContainerPolicy#Open_Issues)
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.
-Tom
Douglas Clarke wrote:
Tom,
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?
Doug
-----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
Features
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.
http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/Extended_Map_support
http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/Extended_Map_support/MappedKeyMapContainerPolicy
Thanks,
tom
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
