Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] ER200040: New native XML metadata functionalspec

Thanks for the feedback. See my comments below.
----- Original Message -----
Sent: Tuesday, December 04, 2007 9:47 AM
Subject: Re: [eclipselink-dev] ER200040: New native XML metadata functionalspec

    In the EclipseLink-ORM.XML Override and Merging section the functional spec indicates that users will be required to name the EclipseLink-ORM.xml file "eclipselink-orm.xml" or it will not be processed as an EclipseLink specific file.  It seems that this could be problematic for schema validation.   Also, user's of JPA have come to expect that they can name the config files by model specific names (ie employee.xml).   There should be no technical barrier to allowing users arbitrary EclipseLink-ORM.xml file names.  Why is this limitation being suggested?
With the new XML overlaying capability we are introducing, only one XML file (the eclipselink-orm.xml) is annotated with that special capability. Users can therefore keep their existing PU's as defined and set the eclipselink-orm.xml with extended EclipseLink functionality they would like to overlay across their PU XML metadata.
Note, it is possible for every mapping file across the PU to either be configured as an eclipselink or JPA file. However this could lead to portability issues. Also, the eclipselink-orm.xml will be discovered automatically if not specified in the persistence.xml (similarly to the orm.xml). Therefore providing another option to the users to remain portable.
So in summary, the eclipselink-orm.xml is special in two ways:
1 - It provides overlays to apply againts other mapping files in the PU
2 - It may also provide full definition of entities as any other mapping file would.
I just finished having a discussion with Gord about this, what he is suggesting is allowing multiple EclipseLink mapping files within a PU to have the overlay capability (regardless of the name of the file). Any other thoughts or comments on this functionality from others on the mailing list?
I tend to favor the one file approach for EclipseLink extensions. Otherwise, I believe if the user is going to defined multiple EclipseLink files then they should just be complete specifications and each file is treated just like any other mapping file (be it JPA or EclipseLink).

metadata-complete - Given the spirit of metadata-complete, if metadata-compete is specified within the EclipseLink-ORM.xml file then all other configuration (orm.xml and annotations) should be ignored for that element (entity, embeddable...) and any unspecified config defaulted.  metadata-complete currently mean ignore the other config information and we should propagate that meaning to our usage.
Before I answer, I'd like to touch on the current functionality:
The current metada-complete functionality can be applied per entity or per persistence-unit
1 - Per persistence unit - if specified then the complete set of mapping metadata for the persistence unit is contained in the XML mapping files for the persistence unit.
2 - Per entity, applies only to that entity.
Under the current JPA implementation it is an error to define the persistence-unit-metadata in multiple files.
What is proposed in the FS is to allow the persistence unit metadata to be defined in the eclipselink-orm.file so that users can extend (or fully defined) the contents of the persistence unit metadata there.
So you are suggesting two things:
1 - At the persistence-unit level if metadata-complete is specified in the eclipselink-orm.xml then no other mapping file will be processed?
2 - If specified at the entity-level in the eclipselink-orm.xml, then no overlay occurs and the metadata for that entity in the eclipselink-orm.xml is treated as the source of truth.
I'm not sure I would agree with that. I would rather see the functionality of metadata-complete remain as defined in JPA and introcude an new element say (eclipselink-metadata-complete) which can specified in the eclipselink-orm.xml (at the persistence-unit or entity level) to provide this functionality.

Use case3.  Why is this ambiguous? when using either your rules or my suggestions the result  should be : Entity A will contain the mapping b (from orm.xml) and mapping c and d (from eclipse-orm.xml) and mapping x (from some-other-mapping-file).  If it truly is undefined then EclipseLink should be throwing an exception as we should not be leaving the user in on undetermined state.
This is ambiguous because, regardless if the eclipse-orm.xml file is defined or not, currently in EclipseLink's JPA implemention, an Entity defined in two mapping files will produce an ambiguous case for two reasons:
 1- The processing order of mapping files is not defined
 2- The last file processed will win

"JPA + Oracle TopLink loading is currently not supported. That is, user's cannot load JPA against an existing Oracle TopLink server session, they are mutually exclusive. Do we want to introduce this functionality? "
-What does this mean?  What is meant my JPA?  This format should be loadable (including annotations) into a project that could be loaded into an existing ServerSession?
What is meant here, is that a JPA deployment can not be configured over an existing ServerSession. That is, a new ServerSession is built for every deployement and there is no option to configure over an existing session. If the user loads an EclipseLink deployment xml through EclipseLink's JPA properties, the ServerSession that is loaded is treated as the source of truth for that persistence unit (and no other metadata is loaded onto it, be it XML or annotations)


Guy Pelletier wrote:
Below is a link to our functional spec for the EclipseLink-ORM.XML schema definition. The EclipseLink-ORM.XML schema is an extension from the JPA schema that is designed to allow users to leverage the extra features from EclipseLink that are not covered within the JPA schema.
I would appreciate any and all feedback/questions/comments and ask that you please submit them no later than Tuesday, December 4th.

eclipselink-dev mailing list

Back to the top