Re: Using query hints for mapping extensions in orm.xml
Has there been any progress on this issue? I just came across a case today where I'd like this functionality and some searching turned up this thread. I don't see anything on this subject that is more recent than the email below, but I'm not sure that I'm not just looking in the wrong places. Thanks. On Jan 25, 2007, at 1:07 PM, Patrick Linskey wrote: ... and option 4 is: - user creates an orm.xml using the Sun XSD. This contains only JPA-standard options, and is thus portable. - user also creates an openjpa-orm.xml file using the OpenJPA XSD as discussed already (or potentially a new OpenJPA-only XSD). This contains only OpenJPA extension options. Again, the application is therefore portable -- other vendors will clearly ignore the openjpa-orm.xsd file. -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: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Thursday, January 25, 2007 9:26 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Using query hints for mapping extensions in orm.xml Let's put this into a more concrete terms: Given: 1) Existing JPA orm schema in http://java.sun.com/xml/ns/persistence/orm_1_0.xsd 2) OpenJPA supports its version of the orm schema in http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa _orm_1_0.xsd Note: we need to find a more permanent home for this schema other than putting it in incubator.apache.org. Suggestions? 3) xml name space for both schema are: xmlns="http://java.sun.com/xml/ns/persistence/orm"; xmlns:openjpa="http://java.sun.com/xml/ns/persistence/orm"; Note: Both schema MUST be in the same name space due to schma redefine restriction. Use cases: 1) application specifies orm_1_0.xsd in the orm.xml - portable to other providers - no openjpa specific functions allow. 2) application specifies openjpa_orm_1_0.xsd in orm.xml - only "guarantee" to work with openjpa provider. - openjpa functions must be specified according to openjpa orm additional schema. - Can use the combination of persistence.xml and orm.xml stanza to enforce the orm must be applied using openjpa provider. persistence.xml org.apache.openjpa.persistence.PersistenceProviderImpl META-INF/openjpa_orm.xml .. openjpa_orm.xml http://java.sun.com/xml/ns/persistence/orm http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa _orm_1_0.xsd"> 3) No schema is specified in the orm.xml (least desirable option) - openjpa functions may be added to orm.xml. OpenJPA tolerates this option - There is no validation on the stanza, hence may be problematic in processing/handling of the stanza. - No guarantee this will work in other providers. - But this option is the least restrictive in orm usage All three options are available for use by an application, in order of compliance and portability preferences. Albert Lee. On 1/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: Firstly, thanks for putting this together. I don't think that portability is a huge problem. I agree with the three scenarios that Albert mentioned, but I think that we can refine #1: 1) if an application wants to be fully portable between providers, the standard orm.xsd must be specified. This will inhibit the use of openjpa features. I would revise this as follows: 1) if an application wants to be fully portable between providers, the standard orm.xsd must be specified. This will inhibit the use of OpenJPA features in that file, so a parallel openjpa-orm.xml file must be used which conforms to the OpenJPA XSD and adds the additional information. We could even create a second XSD for that situation that allows only OpenJPA content to help prevent people from putting conflicting stanzas in the two files. -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
RE: Using query hints for mapping extensions in orm.xml
... and option 4 is: - user creates an orm.xml using the Sun XSD. This contains only JPA-standard options, and is thus portable. - user also creates an openjpa-orm.xml file using the OpenJPA XSD as discussed already (or potentially a new OpenJPA-only XSD). This contains only OpenJPA extension options. Again, the application is therefore portable -- other vendors will clearly ignore the openjpa-orm.xsd file. -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: Albert Lee [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 25, 2007 9:26 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Using query hints for mapping extensions in orm.xml > > Let's put this into a more concrete terms: > > Given: > 1) Existing JPA orm schema in > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd > > 2) OpenJPA supports its version of the orm schema in > > http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa > _orm_1_0.xsd >Note: we need to find a more permanent home for this > schema other > than putting it in incubator.apache.org. Suggestions? > > 3) xml name space for both schema are: > > xmlns="http://java.sun.com/xml/ns/persistence/orm"; > xmlns:openjpa="http://java.sun.com/xml/ns/persistence/orm"; >Note: Both schema MUST be in the same name space due to schma > redefine restriction. > > Use cases: > 1) application specifies orm_1_0.xsd in the orm.xml > - portable to other providers > - no openjpa specific functions allow. > > 2) application specifies openjpa_orm_1_0.xsd in orm.xml > - only "guarantee" to work with openjpa provider. > - openjpa functions must be specified according to openjpa orm > additional schema. > - Can use the combination of persistence.xml and > orm.xml > stanza to enforce > the orm must be applied using openjpa provider. > > persistence.xml > > > > org.apache.openjpa.persistence.PersistenceProviderImpl > > META-INF/openjpa_orm.xml > .. > openjpa_orm.xml > xsi:schemaLocation=" > http://java.sun.com/xml/ns/persistence/orm > > http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa > _orm_1_0.xsd"> > > > 3) No schema is specified in the orm.xml (least desirable option) > - openjpa functions may be added to orm.xml. OpenJPA > tolerates this > option > - There is no validation on the stanza, hence may be > problematic in > processing/handling of the stanza. > - No guarantee this will work in other providers. > - But this option is the least restrictive in orm usage > > All three options are available for use by an application, in order of > compliance and portability preferences. > > Albert Lee. > > On 1/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > Firstly, thanks for putting this together. > > > > I don't think that portability is a huge problem. I agree > with the three > > scenarios that Albert mentioned, but I think that we can refine #1: > > > > > 1) if an application wants to be fully portable between > providers, the > > > standard orm.xsd must be specified. This will inhibit the use > > > of openjpa > > > features. > > > > I would revise this as follows: > > > > 1) if an application wants to be fully portable between > providers, the > > standard orm.xsd must be specified. This will inhibit the > use of OpenJPA > > features in that file, so a parallel openjpa-orm.xml file > must be used > > which conforms to the OpenJPA XSD and adds the additional > information. > > > > We could even create a second XSD for that situation that > allows only > > OpenJPA content to help prevent people from putting > conflicting stanzas > > in the two files. > > > > -Patrick > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > > > _
Re: Using query hints for mapping extensions in orm.xml
Let's put this into a more concrete terms: Given: 1) Existing JPA orm schema in http://java.sun.com/xml/ns/persistence/orm_1_0.xsd 2) OpenJPA supports its version of the orm schema in http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa_orm_1_0.xsd Note: we need to find a more permanent home for this schema other than putting it in incubator.apache.org. Suggestions? 3) xml name space for both schema are: xmlns="http://java.sun.com/xml/ns/persistence/orm"; xmlns:openjpa="http://java.sun.com/xml/ns/persistence/orm"; Note: Both schema MUST be in the same name space due to schma redefine restriction. Use cases: 1) application specifies orm_1_0.xsd in the orm.xml - portable to other providers - no openjpa specific functions allow. 2) application specifies openjpa_orm_1_0.xsd in orm.xml - only "guarantee" to work with openjpa provider. - openjpa functions must be specified according to openjpa orm additional schema. - Can use the combination of persistence.xml and orm.xml stanza to enforce the orm must be applied using openjpa provider. persistence.xml org.apache.openjpa.persistence.PersistenceProviderImpl META-INF/openjpa_orm.xml .. openjpa_orm.xml http://java.sun.com/xml/ns/persistence/orm http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa_orm_1_0.xsd";> 3) No schema is specified in the orm.xml (least desirable option) - openjpa functions may be added to orm.xml. OpenJPA tolerates this option - There is no validation on the stanza, hence may be problematic in processing/handling of the stanza. - No guarantee this will work in other providers. - But this option is the least restrictive in orm usage All three options are available for use by an application, in order of compliance and portability preferences. Albert Lee. On 1/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: Firstly, thanks for putting this together. I don't think that portability is a huge problem. I agree with the three scenarios that Albert mentioned, but I think that we can refine #1: > 1) if an application wants to be fully portable between providers, the > standard orm.xsd must be specified. This will inhibit the use > of openjpa > features. I would revise this as follows: 1) if an application wants to be fully portable between providers, the standard orm.xsd must be specified. This will inhibit the use of OpenJPA features in that file, so a parallel openjpa-orm.xml file must be used which conforms to the OpenJPA XSD and adds the additional information. We could even create a second XSD for that situation that allows only OpenJPA content to help prevent people from putting conflicting stanzas in the two files. -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: Albert Lee [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 24, 2007 8:38 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Using query hints for mapping extensions in orm.xml > > First, I would not expected other providers will handle the special > openjpa.orm.xsd even if it is spec'ed out in the document > header. If they > choose to ignore the new schema and proceed to parse the > document content > using the standard orm.xsd, then any openjpa specific stanza > will probably > be flagged as non-compliance. > > The other scenario is: what about if the document does not specify the > schema at all, like the original sample. I suspect most providers will > tolerate this scenario, just like openjpa does. > > Can the solutions be: > 1) if an application wants to be fully portable between providers, the > standard orm.xsd must be specified. This will inhibit the use > of openjpa > features. > 2) if an application wants to use openjpa specific stanza and > still be used > by other provider, don't specify the schema at all in the > document. Hoping > the other providers will tolerate and ignore the openjpa features. > 3) if an application wants to be openjpa schema compliance, then use > openjpa.orm.xsd in the document header and openjpa can validate the > document. However this
RE: Using query hints for mapping extensions in orm.xml
Firstly, thanks for putting this together. I don't think that portability is a huge problem. I agree with the three scenarios that Albert mentioned, but I think that we can refine #1: > 1) if an application wants to be fully portable between providers, the > standard orm.xsd must be specified. This will inhibit the use > of openjpa > features. I would revise this as follows: 1) if an application wants to be fully portable between providers, the standard orm.xsd must be specified. This will inhibit the use of OpenJPA features in that file, so a parallel openjpa-orm.xml file must be used which conforms to the OpenJPA XSD and adds the additional information. We could even create a second XSD for that situation that allows only OpenJPA content to help prevent people from putting conflicting stanzas in the two files. -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: Albert Lee [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 24, 2007 8:38 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Using query hints for mapping extensions in orm.xml > > First, I would not expected other providers will handle the special > openjpa.orm.xsd even if it is spec'ed out in the document > header. If they > choose to ignore the new schema and proceed to parse the > document content > using the standard orm.xsd, then any openjpa specific stanza > will probably > be flagged as non-compliance. > > The other scenario is: what about if the document does not specify the > schema at all, like the original sample. I suspect most providers will > tolerate this scenario, just like openjpa does. > > Can the solutions be: > 1) if an application wants to be fully portable between providers, the > standard orm.xsd must be specified. This will inhibit the use > of openjpa > features. > 2) if an application wants to use openjpa specific stanza and > still be used > by other provider, don't specify the schema at all in the > document. Hoping > the other providers will tolerate and ignore the openjpa features. > 3) if an application wants to be openjpa schema compliance, then use > openjpa.orm.xsd in the document header and openjpa can validate the > document. However this will prevent the application to be > portable to other > providers. > > Albert Lee. > > > On 1/24/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > > > Thank you, Albert, for your experimentation. The updated schema > > definition > > (openjpa_orm_1_0.xsd) and the example openjpa_orm.xml seems > to be what we > > are looking for. I guess the only concern is whether we > can count on > > other > > JPA implementations to ignore this extra schema definition > and just rely > > on > > the standard orm.xsd. > > > > Question: Even if other JPA providers are smart enough to > ignore our > > specialized schema and use the standard JPA schema, what > happens to our > > extension elements? Do they get ignored as well? Or, will the > > verification > > step still trip over these new/updated elements? > > > > Thanks again, > > Kevin > > > > > > On 1/23/07, Albert Lee <[EMAIL PROTECTED]> wrote: > > > > > > Somehow the one of the attachment (openjpa_orm_1_0.xsd) > from my previous > > > note did not make it to this forum. > > > > > > Try again here. > > > > > > -- > > > > > > > > > > > > > > > version="1.0" > > >xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > > > targetNamespace=" > http://java.sun.com/xml/ns/persistence/orm"; > > > > xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"; > > > elementFormDefault="qualified" > > > attributeFormDefault="unqualified" > > > > > > > > > > > > > > > > @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 > > >
Re: Using query hints for mapping extensions in orm.xml
First, I would not expected other providers will handle the special openjpa.orm.xsd even if it is spec'ed out in the document header. If they choose to ignore the new schema and proceed to parse the document content using the standard orm.xsd, then any openjpa specific stanza will probably be flagged as non-compliance. The other scenario is: what about if the document does not specify the schema at all, like the original sample. I suspect most providers will tolerate this scenario, just like openjpa does. Can the solutions be: 1) if an application wants to be fully portable between providers, the standard orm.xsd must be specified. This will inhibit the use of openjpa features. 2) if an application wants to use openjpa specific stanza and still be used by other provider, don't specify the schema at all in the document. Hoping the other providers will tolerate and ignore the openjpa features. 3) if an application wants to be openjpa schema compliance, then use openjpa.orm.xsd in the document header and openjpa can validate the document. However this will prevent the application to be portable to other providers. Albert Lee. On 1/24/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: Thank you, Albert, for your experimentation. The updated schema definition (openjpa_orm_1_0.xsd) and the example openjpa_orm.xml seems to be what we are looking for. I guess the only concern is whether we can count on other JPA implementations to ignore this extra schema definition and just rely on the standard orm.xsd. Question: Even if other JPA providers are smart enough to ignore our specialized schema and use the standard JPA schema, what happens to our extension elements? Do they get ignored as well? Or, will the verification step still trip over these new/updated elements? Thanks again, Kevin On 1/23/07, Albert Lee <[EMAIL PROTECTED]> wrote: > > Somehow the one of the attachment (openjpa_orm_1_0.xsd) from my previous > note did not make it to this forum. > > Try again here. > -- > > > > version="1.0" >xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > targetNamespace=" http://java.sun.com/xml/ns/persistence/orm"; >xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"; > elementFormDefault="qualified" > attributeFormDefault="unqualified" > > > > > > @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 > > > > > > > > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd > "> > > > > > > > minOccurs="0" maxOccurs="1" default="false"/> > > > > > > > > > > > > > minOccurs="0" maxOccurs="1" default="false"/> > > maxOccurs="1" default="parallel"> > > > > > > > > > > > > > > > > > > > Albert Lee >
Re: Using query hints for mapping extensions in orm.xml
Thank you, Albert, for your experimentation. The updated schema definition (openjpa_orm_1_0.xsd) and the example openjpa_orm.xml seems to be what we are looking for. I guess the only concern is whether we can count on other JPA implementations to ignore this extra schema definition and just rely on the standard orm.xsd. Question: Even if other JPA providers are smart enough to ignore our specialized schema and use the standard JPA schema, what happens to our extension elements? Do they get ignored as well? Or, will the verification step still trip over these new/updated elements? Thanks again, Kevin On 1/23/07, Albert Lee <[EMAIL PROTECTED]> wrote: Somehow the one of the attachment (openjpa_orm_1_0.xsd) from my previous note did not make it to this forum. Try again here. -- http://www.w3.org/2001/XMLSchema"; targetNamespace=" http://java.sun.com/xml/ns/persistence/orm"; xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"; elementFormDefault="qualified" attributeFormDefault="unqualified" > @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 http://java.sun.com/xml/ns/persistence/orm_1_0.xsd "> Albert Lee
Re: Using query hints for mapping extensions in orm.xml
Somehow the one of the attachment (openjpa_orm_1_0.xsd) from my previous note did not make it to this forum. Try again here. -- http://www.w3.org/2001/XMLSchema"; targetNamespace="http://java.sun.com/xml/ns/persistence/orm"; xmlns:orm="http://java.sun.com/xml/ns/persistence/orm"; elementFormDefault="qualified" attributeFormDefault="unqualified" > @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 http://java.sun.com/xml/ns/persistence/orm_1_0.xsd";> Albert Lee
Re: Using query hints for mapping extensions in orm.xml
I assume the test passed the uses http://java.sun.com/xml/ns/persistence/orm"; xmlns:openjpa=" http://incubator.apache.org/openjpa/orm";> Since this header does not specify what schema to use, the openjpa xml parser probably skipped the xml validation. To enable xml validation the following header should be used: http://www.w3.org/2001/XMLSchema-instance " xmlns="http://java.sun.com/xml/ns/persistence/orm"; xmlns:openjpa=" http://java.sun.com/xml/ns/persistence/orm"; xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"; > The orm_1_0.xsd does not recognize the new openjpa someelement stanza and the xml validator will choke with an error/exception. I have experimented a little with extending the orm_1_0.xsd schema to accommodate possible openjpa specific stanza. Here are some findings: 1) There are 2 forms of extensions: a) add in various strategic locations in orm_1_0.xsd to allow unspecified user free form extensions. b) extends orm_1_0.xsd to openjpa specific schema (e.g. openjpa_orm_1_0.xsd) using 2) The ideal solution is a) because this will allow providers to correctly parse orm.xml with any extensions and ignore those that it does not understand. Hence orm_1_0.xsd has already casted in stone and any changes will have to wait until next JPA version. 3) The next to ideal solution is b). The advantage of this approach is one can naturally specify provider specific stanza to the associated elements in orm.xml (e.g. ). The "redefine" of the schema is also pretty straight forward to do. The down side is the orm.xml has to specify the openjpa orm schema instead of the standard orm_1_0.xsd. This will potentially prohibit other providers not to accept the orm.xml. Theoretically, provider should detect the schema used as specified in "schemaLocation" in the header and parse the orm.xml content accordingly. Not all providers are robust enough to handle this properly. I have attached a validated sample of the openjpa_orm_1_0.xsd schema that accept 3 new openjpa specific stanza as described in previous example and a validated sample of the instance of the orm.xml document that uses the new schema. (Note One needs to update the xsi:schemaLocation to point to an valid location of openjpa_orm_1_0.xsd) Albert Lee On 1/22/07, Craig L Russell < [EMAIL PROTECTED]> wrote: 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 < [EMAIL PROTECTED]> 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...): >>> > >>> > >>> > http://java.sun.com/xml/ns/persistence/ >>> orm" >>> > 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 prov
Re: Using query hints for mapping extensions in orm.xml
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 <[EMAIL PROTECTED]> 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...): > > > http://java.sun.com/xml/ns/persistence/ orm" > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 hin
Re: Using query hints for mapping extensions in orm.xml
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 <[EMAIL PROTECTED]> 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...): > > > http://java.sun.com/xml/ns/persistence/orm"; > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 i
Re: Using query hints for mapping extensions in orm.xml
IIRC this sort of extension would only be allowed if the original schema "http://java.sun.com/xml/ns/persistence/orm"; has explicitly allowed extension. Historically, Sun has made it impossible to extend their xml documents. -dain 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 <[EMAIL PROTECTED]> 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...): > > > http://java.sun.com/xml/ns/persistence/orm"; > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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. >> >>
Re: Using query hints for mapping extensions in orm.xml
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 <[EMAIL PROTECTED]> 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...): > > > http://java.sun.com/xml/ns/persistence/orm"; > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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). >> >> >> >> >> >> >> >> >>
Re: Using query hints for mapping extensions in orm.xml
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...): http://java.sun.com/xml/ns/persistence/orm"; version="1.0" xmlns:openjpa="http://incubator.apache.org/openjpa/orm";> org.apache.openjpa.mappingextensions false parallelmode> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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). >> >> >> >> >> http://java.sun.com/xml/ns/persistence/ orm" >> 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Using query hints for mapping extensions in orm.xml
Hi Kevin, I'm not either an expert in namespaces, which is why I didn't follow in the first place ;-) 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...): http://java.sun.com/xml/ns/persistence/orm"; version="1.0" xmlns:openjpa="http://incubator.apache.org/openjpa/orm";> org.apache.openjpa.mappingextensions false parallelmode> If I understand xml correctly, this is illegal unless the persistence/ orm explicitly allows an element of type openjpa:jdbc-eager-fetch- mode or ANY to be a member element of one-to-many. So I don't see how it can work. Craig 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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). >> >> >> >> >> http://java.sun.com/xml/ns/persistence/ orm" >> version="1.0"> >> org.apache.openjpa.mappingextensions >> >> >> >> >> >> >> >> >> >> >> >> >> >> > value="parallel"/> >> > value="true"/> >> >> >> >> >> >> >> >> >> >
Re: Using query hints for mapping extensions in orm.xml
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...): http://java.sun.com/xml/ns/persistence/orm"; version="1.0" xmlns:openjpa="http://incubator.apache.org/openjpa/orm";> org.apache.openjpa.mappingextensions false parallel 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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). >> >> >> >> >> http://java.sun.com/xml/ns/persistence/orm"; >> 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Using query hints for mapping extensions in orm.xml
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:[EMAIL PROTECTED] 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). http://java.sun.com/xml/ns/persistence/orm"; version="1.0"> org.apache.openjpa.mappingextensions Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Using query hints for mapping extensions in orm.xml
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. -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:[EMAIL PROTECTED] 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). > > > > > http://java.sun.com/xml/ns/persistence/orm"; > version="1.0"> > org.apache.openjpa.mappingextensions > > > > > > > > > > > > > > value="parallel"/> > value="true"/> > > > > > > > > > > > > > > > > > > > > >
Re: Using query hints for mapping extensions in orm.xml
I think this is the way to do it. Isn't this what the QueryHints are intended to do - to allow vendor specific query extensions to hook in :-) Cheers, Rahul Marc Prud'hommeaux wrote: 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). http://java.sun.com/xml/ns/persistence/orm"; version="1.0"> org.apache.openjpa.mappingextensions value="parallel"/> value="true"/>
