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 Tue, 24 Jul 2007 22:17:33 GMT
David-

I think that sums up the pros and cons pretty well. My only 2 comments:

> persistence-xxx and jdbc-xxx where xxx is the simple name of the  
> annotation

I'd vote for just "xxx" and "jdbc-xxx" (due to a strong dislike for  
over-long XML names).

> b) the annotations do not contain any information on where they
> can occur within the JPA ORM elements.

True, although we could just say that class-level annotations go  
under the <entity> element, and field-level annotations go under the  
fields's element (<basic>, <one-to-one>, etc.). That would cover all  
of the top-level annotations, and then the rest of them would have  
their hierarchy defined by their own annotation structure (e.g.,  
@FetchGroups already knows that it contains an array of @FetchGroup  
annotations).




On Jul 24, 2007, at 2:52 PM, David Ezzio wrote:

> Hi Marc and Patrick,
>
> Thanks for your early feedback. Let's see if I understand the  
> important
> points:
>
> 1. Leverage the information in the OpenJPA annotations to autogenerate
> the XSD document. The XSD schema will have an XML element per
> annotation. Use some aliases (I'm thinking persistence-xxx and jdbc- 
> xxx
> where xxx is the simple name of the annotation) to make the element
> labels easy to use.
>
> 2. We would autogenerate some of the parsing code or otherwise use the
> annotations for the parsing as well.
>
> 3. The autogeneration would occur as part of the OpenJPA build.
>
> There are several advantages of this approach: a) the OpenJPA ORM XSD
> types will be generated according to a uniform transformation of the
> annotations. The hope is that there will be no customization of the
> autogeneration for specific annotations. b) we will have an XML  
> element
> per annotation which is the most intuitive approach (easiest  
> learned and
> documented). c) we would have uniform semantics for both  
> annotations and
> XML. d) we could add autogenerators. For example, if we started  
> with an
> autogenerated combined JPA-OpenJPA ORM schema, we could add an
> autogenerator for standalone OpenJPA ORM documents, or vice-versa.
>
> The are a couple of disadvantages. a) we don't want the autogeneration
> code to become the place where a thousand tweaks are needed to support
> diverging XML and annotations. We can make the design rule that there
> will be no XML without a corresponding annotation that it  
> autogenerates
> from. b) the annotations do not contain any information on where they
> can occur within the JPA ORM elements. We will need to encode this
> information for the autogeneration in a separate file. This  
> information
> will allow us to autogenerate overriding types for the JPA ORM types.
>
>
> David
>
>>
>>
>> -------- Original Message --------
>> Subject: Re: Preliminary design for supporting OpenJPA annotations in
>> XML metadata.
>> Date: Fri, 20 Jul 2007 15:24:24 -0700
>> From: Marc Prud'hommeaux <mprudhom@apache.org>
>> Reply-To: dev@openjpa.apache.org
>> To: dev@openjpa.apache.org
>> References: <46A11463.8050904@bea.com>
>> <C6685C2D-D033-44D8-B96F-17E37F2BD37C@apache.org>
>> <7262f25e0707201457vced50b8o65c6a45668ec1a56@mail.gmail.com>
>>
>>
>> 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
>>
>>
>>
>>
>
>
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries   
> and  affiliated entities,  that may be confidential,  proprietary,   
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.


Mime
View raw message