Community
Participate
Working Groups
Currently EclipseLink supports a native XML metadata format derived from Oracle TopLink. It supports verbose ORM, OXM, and EIS mapping. This file format must be enhanced to support: 1. Alignment with JPA so consumers can choose to use this file to extend/override a JPA ORM.XML configuration with naming ans structure alignment. This means that values specified in the JPA ORM.XML may be omitted except for those required for scoping of the extended configuration (i.e. attribute name) 2. Consumers can use this file exclusively. This means that they can choose to use this single file and configure all values including those that could be specified in the JPA ORM.XML 3. The XML documents customers create must be human readable and as easy to understand as possible. Minimal configuration should be used allowing defaults to be assumed wherever possible. 4. Configuration of top level data access queries using SQL or stored procedures. Basically definition of session queries. This must be possible also in cases where no entity mappings are defined. The intent is to allow simplified data access use cases. 5. Support for dynamic entity persistence where no concrete entity exists. This configuration will need to be designed in coordination with the ER (to be filed) formalizing the dynamic persistence capabilities used in DBWS.
Created attachment 88166 [details] EclipseLink core changes
Created attachment 88167 [details] EclipseLink jpa changes
Created attachment 88168 [details] EclipseLink jpa test changes
Created attachment 90099 [details] Changes to EclipseLink ORM schema from bug 217877
Created attachment 90352 [details] Changes to EclipseLink ORM schema from bug 217878
There should be no undefined behavior in how we process mapping files. In the FS section "EclipseLink-ORM.XML Override and Merging" it states: "regardless if it conforms to the EclipseLink-ORM.XML schema will be treated no differently than any other JPA ORM.XML file. If there are overlapping specifications in multiple orm files, the last file read will win and there is no guarantee in which order the mapping files will be processed. NOTE: The order the files are listed in the persistence.xml file does not not guarantee that they will be processed in that order."
Agreed. Just because the spec does not define the behavior does not mean that we can't come up with a behavior that is describable and predictable. In fact, the spec is undefined to allow different vendors to come up with different strategies for supporting these situations. It would be a lot nicer if we could draw lines around what we will allow and what we won't. We shouldn't have any grey area, but should define exactly what will and what won't work, and then do the checking to ensure that people do not get caught somewhere in the black zone without knowing it.
Created attachment 90671 [details] Changes to EclipseLink ORM schema from bug 217879
Created attachment 91018 [details] Changes to EclipseLink ORM schema from bug 217880
Created attachment 91406 [details] Changes to EclipseLink ORM schema from bug 217883
Created attachment 94272 [details] Changes to EclipseLink ORM schema from bug 211302
Created attachment 95250 [details] Changes to EclipseLink ORM schema from bug 224155
Created attachment 96137 [details] Changes to EclipseLink ORM schema from bug 226517
Created attachment 101798 [details] Changes to EclipseLink ORM schema from bug 211330
All the sub bugs have now been fixed. Changing the status of this bug to resovled fixed.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
