openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ezzio <dez...@bea.com>
Subject Re: Preliminary design for supporting OpenJPA annotations in XML metadata.
Date Tue, 24 Jul 2007 21:52:35 GMT
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