RE: [eclipselink-dev] Updated Design for JPA 2.0 Map Collection Features

[Douglas Clarke <DOUGLAS.CLARKE@xxxxxxxxxx>]

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