David-
I've only looked quickly at your document. Personally, I am a little
concerned about having the approach be based on an XSD document. I
think that we have sufficient information in our annotations to
define the structure of how the extensions document could be defined.
One of my long-standing concerns with our current
XMLPersistenceMetaDataParser is that if a change is made to the
semantic handling of any of the tags/annotations, then it needs to be
made in 2 places. I feel like all that logic should be centrally
located.
In any case, even if the project doesn't involve unifying the
AnnotationPersistenceMetaDataParser and XMLPersistenceMetaDataParser,
we could still handle the extensions using information already
contained in the annotations. For the purposes of user-friendly
validation and potential tooling support, and XSD could be auto-
generated from the information already contained in the annotations
themselves. For example, looking at ElementForeignKey.java, you can
see how we could auto-generate an XSD that validates the following
document:
<openjpa:org.apache.openjpa.persistence.jdbc.MappingOverride
name="myOverride">
<joinColumns>
<openjpa:org.apache.openjpa.persistence.jdbc.XJoinColumns>
<openjpa:org.apache.openjpa.persistence.jdbc.XJoinColumn
name="someName" referencedColumnName="someColumn"/>
<openjpa:org.apache.openjpa.persistence.jdbc.XJoinColumn
name="someOtherName" referencedColumnName="someOtherColumn"/>
</openjpa:org.apache.openjpa.persistence.jdbc.XJoinColumns>
</joinColumns>
<elementJoinColumns>
...
</elementJoinColumns>
<containerTable>
...
</containerTable>
</openjpa:org.apache.openjpa.persistence.jdbc.MappingOverride>
Some extra "alias" variable could be put into our annotations to
allow people to specify, for example, "<openjpa:mapping-override>"
instead of
"<openjpa:org.apache.openjpa.persistence.jdbc.MappingOverride>".
One obvious advantage of being able to auto-generate the XSD from
annotations is that we don't need to consider how to handle
individual annotations on a case-by-case basis, but instead we can
leverage the fact that we already have a defined logical structure in
place.
Another advantage is that it would allow us to generate different
XSDs for different usage scenarios: one XSD could be a unified
orm.xml + openjpa extensions that allows people to define their
mapping and extensions in a single document (although it probably
wouldn't work for other JPA implementations), and another could be an
XSD for an extensions-only separate mapping file.
I think this approach would probably be a bit more work in terms of
making core changes to the behavior of the
XMLPersistenceMetaDataParser, but on the other hand, making it
generic would prevent you from having to assess the semantics of each
new XML tag on a case-by-case basis.
On Jul 20, 2007, at 1:00 PM, David Ezzio (asmtp) wrote:
Hi,
I'm starting to design support of XML metadata for OpenJPA
annotations in order to address OpenJPA-125 and OpenJPA-87.
I've attached a zip containing a preliminary design document, a
sample openjpa_orm_1_0.xsd file and a sample OpenJPA ORM instance.
It took quite a while to create the text document and it is best
viewed as the tracks of a design process. The design that I worked
on the most (the one with the most documentation) is not
necessarily the best design. There are two alternatives suggested,
and there may be others that I haven't thought of.
I think the fundamental choices facing us are these:
1. Do we construct an OpenJPA ORM schema that extends the JPA ORM
schema? Doing so, allows the user to use one metadata file instead
of two, and will enhance maintainability for our users'
applications. Or do we construct a standalone OpenJPA ORM schema?
I've chosen the first option in the preliminary design, and I think
it is the best choice.
2. Do we use a syntactically loose "extension" element format or do
we construct new elements for each supported annotation? Choosing
the first makes it easy (I think) to support newly added
annotations. Choosing the second allows the schema validator to do
most of the validation work. I've chosen the first option in the
preliminary design, but I'm not at all sure of the choice.
3. Do we envision support in XML for all OpenJPA annotations or for
only a subset? If a subset, how do we draw a bright line that will
be consistent and easily documented and followed over time? I've
chosen the first option in the preliminary design simply because
that is the brightest line that I can think of and because it gave
me a chance to look over the field of OpenJPA annotations.
I'll be off on vacation for a week with very limited Internet
connections, so please, take as much time as necessary to consider
the design, and carry on some discussions without me if the spirit
moves you.
Thanks,
David Ezzio<OpenJPA-XML.zip>
