| Re: [eclipselink-dev] ER200040: New native XML metadata functional spec |
|
Guy, 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? 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. 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. "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? --Gordon Guy Pelletier wrote:
|