openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Preliminary design for supporting OpenJPA annotations in XML metadata.
Date Fri, 20 Jul 2007 22:24:24 GMT

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