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 importantpoints: 1. Leverage the information in the OpenJPA annotations to autogenerate the XSD document. The XSD schema will have an XML element perannotation. Use some aliases (I'm thinking persistence-xxx and jdbc- xxxwhere 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 theautogeneration 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 anautogenerated 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 therewill be no XML without a corresponding annotation that it autogeneratesfrom. b) the annotations do not contain any information on where they can occur within the JPA ORM elements. We will need to encode thisinformation for the autogeneration in a separate file. This informationwill 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 <[EMAIL PROTECTED]> Reply-To: [email protected] To: [email protected] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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 thesemantic handling of any of the tags/annotations, then it needs to bemade 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 usersthan 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 itgeneric would prevent you from having to assess the semantics of eachnew XML tag on a case-by-case basis.... but this would mean that if we wanted things to look a bitdifferent for annotations vs. XML, we'd need to invest time and energyin 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 twoparsers. I think that if we went this route, we'd want to be explicitabout 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 <[EMAIL PROTECTED]> wrote:David-I've only looked quickly at your document. Personally, I am a littleconcerned about having the approach be based on an XSD document. I think that we have sufficient information in our annotations todefine 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 thesemantic handling of any of the tags/annotations, then it needs to bemade in 2 places. I feel like all that logic should be centrally located. In any case, even if the project doesn't involve unifying theAnnotationPersistenceMetaDataParser 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 canleverage the fact that we already have a defined logical structure inplace. 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 probablywouldn't work for other JPA implementations), and another could be anXSD 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 itgeneric would prevent you from having to assess the semantics of eachnew 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 bestviewed as the tracks of a design process. The design that I workedon the most (the one with the most documentation) is notnecessarily 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 ORMschema? Doing so, allows the user to use one metadata file insteadof 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 thinkit is the best choice.2. Do we use a syntactically loose "extension" element format or dowe 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 willbe 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 5907Notice: 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.
