On Jul 20, 2007, at 2:57 PM, Patrick Linskey wrote:
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.
This is not a big concern to me -- 2 places isn't much worse than one.
I'm more concerned that we put together the right format for our users
than that everything necessarily comes from a single source.
Well, there are a lot of known problems with our XML handling. For
example, OPENJPA-74 and OPENJPA-179 might have been avoided if we had
centralized handling of our XML/annotations, rather than the massive
switch() statement that is XMLPersistenceMappingParser.
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.
... but this would mean that if we wanted things to look a bit
different for annotations vs. XML, we'd need to invest time and energy
in our auto-XSD-generating tools to make it so. IOW, if we wanted to
let the formats for the XML vs. the annotations differ, we'd end up
doing a lot of auto-generation work instead of just writing two
parsers. I think that if we went this route, we'd want to be explicit
about only supporting converting annotations to XML in a single way.
You are correct that we would be forcing out XML structure to follow
our annotations structure. But I don't see any reason why this would
ever be a bad thing (although I concede that it might sometimes be
somewhat inelegant).
-Patrick
On 7/20/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
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>
--
Patrick Linskey
202 669 5907
