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 21:47:45 GMT
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>


Mime
View raw message