Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 36068 invoked from network); 22 Jan 2007 06:07:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Jan 2007 06:07:33 -0000 Received: (qmail 43901 invoked by uid 500); 22 Jan 2007 06:07:39 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 43878 invoked by uid 500); 22 Jan 2007 06:07:39 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 43869 invoked by uid 99); 22 Jan 2007 06:07:38 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jan 2007 22:07:38 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [192.18.42.249] (HELO nwk-ea-fw-1.sun.com) (192.18.42.249) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jan 2007 22:07:28 -0800 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0M673Hb001191 for ; Sun, 21 Jan 2007 22:07:03 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JC900701A7NAF00@d1-sfbay-09.sun.com> (original mail from Craig.Russell@Sun.COM) for open-jpa-dev@incubator.apache.org; Sun, 21 Jan 2007 22:07:03 -0800 (PST) Received: from [192.168.0.10] (c-24-6-172-77.hsd1.ca.comcast.net [24.6.172.77]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JC9003N2ABQD110@d1-sfbay-09.sun.com> for open-jpa-dev@incubator.apache.org; Sun, 21 Jan 2007 22:07:03 -0800 (PST) Date: Sun, 21 Jan 2007 22:07:01 -0800 From: Craig L Russell Subject: Re: Using query hints for mapping extensions in orm.xml In-reply-to: Sender: Craig.Russell@Sun.COM To: open-jpa-dev@incubator.apache.org Message-id: <060A7895-CBBF-420B-B8BB-28E6B9E1B544@SUN.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-98-12777926; micalg=sha1 References: <7D856CDFE035FF45A0420ACBD71BDD6302DB0EE3@repbex02.amer.bea.com> <5DA65C8D-B2A2-4A33-A2F7-9DCAD94EF7B5@SUN.com> <89c0c52c0701160612t70edc563m777b94d278a4aa44@mail.gmail.com> <82B77D6C-736F-4200-A500-6E60849C5280@apache.org> <89c0c52c0701180616q1dbd07c9rc18edb1aa77e6aa7@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-98-12777926 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed If there is a way to include schema-validation="true" when parsing the orm, I expect that this will throw an exception. Craig On Jan 21, 2007, at 11:59 AM, Marc Prud'hommeaux wrote: > > > Not that I am volunteering to be the resident namespace expert, but > FTR, I tried throwing in a someattribute="somevalue"/> element into an orm.xml, and I notice > that we don't complain when we parse it, so presumably at least our > parse mode doesn't have any problem with it. > > Whether or not other implementations would be more restrictive is > another issue... > > > > On Jan 18, 2007, at 6:16 AM, Kevin Sutter wrote: > >> Do we have any experts with these xml namespaces? Or, anybody >> that wants to >> become an expert? :-) >> It seems like we need a real example of using these to make sure >> they are >> viable. On paper, they look like the solution. But, Craig's >> concern about >> allowing new member elements within existing elements is a valid >> question. >> >> Any volunteers? >> >> Kevin >> >> On 1/16/07, Marc Prud'hommeaux wrote: >>> >>> >>> That indeed does sound like a better solution. >>> >>> >>> On Jan 16, 2007, at 6:12 AM, Kevin Sutter wrote: >>> >>> > Craig, >>> > I'm not an expert with namespaces, but it would be something along >>> > the lines >>> > of first defining the "openjpa" namespace and then specifying the >>> > attributes >>> > qualified by this namespace. We would also need to provide a >>> > schema for >>> > this "openjpa" namespace. Something like this, following on from >>> > Marc's >>> > original example (Patrick, correct me where I'm off a bit...): >>> > >>> > >>> > >> > version="1.0" >>> > xmlns:openjpa="http://incubator.apache.org/openjpa/orm"> >>> > org.apache.openjpa.mappingextensions >>> > >>> > >>> > >>> > >>> > >>> > false >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > parallel>> > mode> >>> > >>> > true >>> > >>> > >>> > >>> > >>> > >>> > The question that I am still not clear on is what the rules are >>> for >>> > "ignoring" these namespace extensions if you don't understand >>> > them. For >>> > example, if another JPA provider reads in one our extended orm.xml >>> > files >>> > with this "openjpa" namespace, how does this provider know to >>> > ignore all of >>> > this extra stuff? I haven't found the rules for this processing. >>> > >>> > If we can clear this up, then I agree with Patrick that namespaces >>> > are the >>> > way to go. They are much cleaner and we're not polluting the >>> original >>> > intent of the orm.xml schema. >>> > >>> > Kevin >>> > >>> > >>> > On 1/15/07, Craig L Russell wrote: >>> >> >>> >> Hi, >>> >> >>> >> On Jan 15, 2007, at 5:12 PM, Patrick Linskey wrote: >>> >> >>> >> > Hi, >>> >> > >>> >> > It kinda feels like we're corrupting the intended use of query >>> >> hints. >>> >> > Plus, it seems unfortunate to have to drop back into untyped >>> >> > strings if >>> >> > we can avoid it. >>> >> > >>> >> > I think that there is another approach that we've talked about >>> >> > earlier: >>> >> > use namespaces to intersperse OpenJPA data into the orm.xml >>> file. >>> >> > That's >>> >> > my preferred solution. >>> >> >>> >> Can you give an example of the usage in your scenario? >>> >> >>> >> Thanks, >>> >> >>> >> Craig >>> >> >>> >> > >>> >> > -Patrick >>> >> > >>> >> > -- >>> >> > Patrick Linskey >>> >> > BEA Systems, Inc. >>> >> > >>> >> > >>> >> >>> ____________________________________________________________________ >>> _ >>> >> _ >>> >> > _ >>> >> > 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. >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On >>> >> >> Behalf Of Marc Prud'hommeaux >>> >> >> Sent: Monday, January 15, 2007 12:26 PM >>> >> >> To: open-jpa-dev@incubator.apache.org >>> >> >> Subject: Using query hints for mapping extensions in orm.xml >>> >> >> >>> >> >> OpenJPA people- >>> >> >> >>> >> >> A limitation of the JPA specification is that there is no >>> built-in >>> >> >> way to put implementation-specific extensions in an orm.xml >>> file, >>> >> >> which limits the use of OpenJPA's many useful extensions to >>> only >>> >> >> being expressible annotations. Past suggestions for getting >>> around >>> >> >> this limitation have been to alter the locally-cached version >>> >> of the >>> >> >> XSD (which would make any orm.xml file that takes advantage of >>> >> this >>> >> >> non-portable) or to have an additional file that contains the >>> >> >> extensions (e.g., an "openjpa-orm.xml" file peered with the >>> >> >> "orm.xml" >>> >> >> file). >>> >> >> >>> >> >> It just occurred to me that there is another possibility: the >>> >> "hint" >>> >> >> child of the "named-query" element is a free-form field that >>> >> acts as >>> >> >> a means to pass a query hint to the implementation. We could >>> >> expand >>> >> >> on this to allow the passing of a mapping hint to the >>> >> implementation >>> >> >> via a special-cased "openjpa.extensions.EntityName" named >>> query in >>> >> >> which we could embed hints for the entity and its attributes. >>> >> >> See the >>> >> >> example below for how it might work. >>> >> >> >>> >> >> What do people think? It would allow us to keep the >>> >> >> extensions in the >>> >> >> same file in which the rest of the mappings are expressed, but >>> >> still >>> >> >> remain portable to other JPA implementations (since other >>> >> >> implementations are supposed to ignore unrecognized query >>> hints). >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> version="1.0"> >>> >> >> org.apache.openjpa.mappingextensions >>> >> >> >>> >> >> >>> >> >>
>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> value="parallel"/> >>> >> >> >> >> >> value="true"/> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >>> >> Craig Russell >>> >> Architect, Sun Java Enterprise System http://java.sun.com/ >>> products/ >>> >> jdo >>> >> 408 276-5638 mailto:Craig.Russell@sun.com >>> >> P.S. A good JDO? O, Gasp! >>> >> >>> >> >>> >> >>> >> >>> >>> > Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp! --Apple-Mail-98-12777926 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7 16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt /CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6 eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+ hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTIyMDYwNzAyWjAjBgkqhkiG9w0B CQQxFgQUAJYJ3qFfgsYzaxYHzyM/BVOo1QkwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG 9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBABDr2s0i9sCd5p9/RGByAk1zgh0PW8JL LAoy9XU2mlKLW6fXTqu04xcEexoRNOb8K631/llat59Xv7Rab+czYUD5TOojVzIkxneTcs9J6RfQ NQkUM5GdO00KMi6CMyncyK7cFvNsqzdXFuXCKTLC7vn9btaXKDZnPS7MqWHXRgIxfhaKH4wVdpos wf+ZB6c3yLJmnBrHD8BHBciK2+U1RV3JB81Z2cPYfAf8d7V4DynAiOzLsfvCiwOf3pB6kMkle2e2 pFUDVMx8hskAqDvb3KNLt/DXv8Mhgp3sNY88JmbpEBDwIu3fojoCdhDq9zz+koc/i40ae3yy4RRn 4ngtvn4AAAAAAAA= --Apple-Mail-98-12777926--