Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 41799 invoked from network); 24 Jul 2007 22:18:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jul 2007 22:18:17 -0000 Received: (qmail 29036 invoked by uid 500); 24 Jul 2007 22:18:18 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 29009 invoked by uid 500); 24 Jul 2007 22:18:17 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 29000 invoked by uid 99); 24 Jul 2007 22:18:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 15:18:17 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of mprudhomapache@gmail.com designates 64.233.162.225 as permitted sender) Received: from [64.233.162.225] (HELO nz-out-0506.google.com) (64.233.162.225) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 15:18:14 -0700 Received: by nz-out-0506.google.com with SMTP id q3so1413369nzb for ; Tue, 24 Jul 2007 15:17:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=fO0Lew/FbTZyu4rqVkL8L94v/yKfLolv0mehcvPCXP4sjXxMxMY5R+CXPCHYlxRYKdC1nefB7UHaADVmUzMPhr+xHUCGLAiVq4XilhmOJkzzicRKjZqp7EmMp7qbcxjPdq3JXgqJKkmrtq154pH22+E9OPKAVvvOlBuQhMTRncU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=o+t4kWIBU8Fh6kntma8eAC3pGIXgisrgFsdTlXOIIpAFJnft+gGqqIpKzEVPnYNa/gd/m24W6Q078ut0icVn6FUfwNmpFv7DTEhu6YuDI15xEGccIDTmgkfbq9YVE+/QpDZc0mZVL5LpoEEDtbFKCoyifQpMY3vg9U0qblSYspE= Received: by 10.141.167.5 with SMTP id u5mr1432929rvo.1185315471979; Tue, 24 Jul 2007 15:17:51 -0700 (PDT) Received: from ?192.168.15.100? ( [66.248.222.34]) by mx.google.com with ESMTPS id l21sm9564821rvb.2007.07.24.15.17.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jul 2007 15:17:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46A674A3.8060601@bea.com> References: <46A17324.2080409@bea.com> <46A674A3.8060601@bea.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DAAD3D2-2162-4A00-B3B0-CA5DD5DEB4E8@apache.org> Content-Transfer-Encoding: 7bit From: Marc Prud'hommeaux Subject: Re: Preliminary design for supporting OpenJPA annotations in XML metadata. Date: Tue, 24 Jul 2007 15:17:33 -0700 To: dev@openjpa.apache.org X-Mailer: Apple Mail (2.752.3) Sender: Marc Prud'hommeaux X-Virus-Checked: Checked by ClamAV on apache.org 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 element, and field-level annotations go under the fields's element (, , 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 >> Reply-To: dev@openjpa.apache.org >> To: dev@openjpa.apache.org >> References: <46A11463.8050904@bea.com> >> >> <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 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: >>>> >>>> >>> name="myOverride"> >>>> >>>> >>>> >>> name="someName" referencedColumnName="someColumn"/> >>>> >>> name="someOtherName" referencedColumnName="someOtherColumn"/> >>>> >>>> >>>> >>>> ... >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> Some extra "alias" variable could be put into our annotations to >>>> allow people to specify, for example, "" >>>> instead of >>>> "". >>>> >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> 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.