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 functional spec

I have a long list of comments that I think we need to meet about (so I don't have to try to explain each of them in email).
A few comments below:
-----Original Message-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx]On Behalf Of Gordon Yorke
Sent: Tuesday, December 04, 2007 9:48 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] ER200040: New native XML metadata functional spec

    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? 
I am kind of split on this one. If 5 files are listed in persistence.xml and one happens to have the el-orm schema in it then it would end up overriding the others. Might be kind of mysterious.

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. 
We do need to talk about what it means for metadata-complete in el-orm.xml because the current description is too weak. The JPA meaning of this is that the sum total of XML mapping metadata is used, so I would argue that specifying this in el-orm.xml means that both orm and el-orm be combined (ie it would be redundant if specified in both files).

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. 
Yes, I would fully expect the mappings to be merged together as well. 

"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? 
I also found this odd. Do you mean that using both JPA mappings files and a EclipseLink proprietary project XML mapping file was not supported?


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.

Back to the top