----- Original Message -----
Sent: Tuesday, December 04, 2007 9:47
AM
Subject: Re: [eclipselink-dev] ER200040:
New native XML metadata functionalspec
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?
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)
