openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: Preliminary design for supporting OpenJPA annotations in XML metadata.
Date Fri, 20 Jul 2007 21:57:37 GMT
> 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.

> 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.

-Patrick

On 7/20/07, Marc Prud'hommeaux <mprudhom@apache.org> 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

Mime
View raw message