From dev-return-5013-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Fri Jul 20 22:25:01 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 42907 invoked from network); 20 Jul 2007 22:24:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Jul 2007 22:24:59 -0000 Received: (qmail 1948 invoked by uid 500); 20 Jul 2007 22:25:01 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 1919 invoked by uid 500); 20 Jul 2007 22:25:01 -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 1909 invoked by uid 99); 20 Jul 2007 22:25:01 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jul 2007 15:25:01 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=RCVD_IN_SORBS_WEB,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of mprudhomapache@gmail.com designates 64.233.162.228 as permitted sender) Received: from [64.233.162.228] (HELO nz-out-0506.google.com) (64.233.162.228) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jul 2007 15:24:58 -0700 Received: by nz-out-0506.google.com with SMTP id q3so828821nzb for ; Fri, 20 Jul 2007 15:24:37 -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=AweWw2/sTY6/3NzyApK1Jk00AhQS4L0vdqw1TNPmDllGt9Ks0vZEpf1cqX860+C8CvoPq1E01OeJ2LfgxhIJXhvk5QDS66Tq1/AKwyb65tvDtTqcrBf+DnAYk0tPNSyJkeNABpWHSWoAgmgxz5lTaosrvhd5zY88l53Q87w6GNU= 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=OWbhKnyinu/lMmnpgmPzq8bGXPNVTD3SJPj7qZxYE1u6F/Wk7UeMpUwEV470KiKm2dfRtAmMvRGyFv6PlsXX9HbTn5CHwD/4l+m4eu5xdPD9FlQuDNaVb7CaKLlT2gwukY2LNYTNKp8P4uJeEHaMCjH1qvVeIQt3CvBbOqQenkw= Received: by 10.141.88.3 with SMTP id q3mr258244rvl.1184970277059; Fri, 20 Jul 2007 15:24:37 -0700 (PDT) Received: from ?192.168.15.101? ( [66.248.222.34]) by mx.google.com with ESMTPS id b34sm6574617rvf.2007.07.20.15.24.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jul 2007 15:24:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7262f25e0707201457vced50b8o65c6a45668ec1a56@mail.gmail.com> References: <46A11463.8050904@bea.com> <7262f25e0707201457vced50b8o65c6a45668ec1a56@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7645A7CE-24D0-4276-AD64-CAD6FB79ED66@apache.org> Content-Transfer-Encoding: 7bit From: Marc Prud'hommeaux Subject: Re: Preliminary design for supporting OpenJPA annotations in XML metadata. Date: Fri, 20 Jul 2007 15:24:24 -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 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