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 provider and orm.xmlentity-mappings xsi:schemaLocation=..openjpa_orm_1_0.xsd stanza to enforce the orm must be applied using openjpa provider. persistence.xml persistence ... persistence-unit name=MyEmployeePU provider org.apache.openjpa.persistence.PersistenceProviderImpl/provider mapping-fileMETA-INF/openjpa_orm.xml/mapping-file .. openjpa_orm.xml entity-mappings . 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. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may
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 provider and orm.xmlentity-mappings xsi:schemaLocation=..openjpa_orm_1_0.xsd stanza to enforce the orm must be applied using openjpa provider. persistence.xml persistence ... persistence-unit name=MyEmployeePU provider org.apache.openjpa.persistence.PersistenceProviderImpl/provider mapping-fileMETA-INF/openjpa_orm.xml/mapping-file .. openjpa_orm.xml entity-mappings . 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. ___ 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
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 provider and orm.xmlentity-mappings xsi:schemaLocation=..openjpa_orm_1_0.xsd stanza to enforce the orm must be applied using openjpa provider. persistence.xml persistence ... persistence-unit name=MyEmployeePU provider org.apache.openjpa.persistence.PersistenceProviderImpl/provider mapping-fileMETA-INF/openjpa_orm.xml/mapping-file .. openjpa_orm.xml entity-mappings . 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. __ _ 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
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. -- ?xml version=1.0 encoding=UTF-8? !-- OpenJPA specific orm.xml schema locates in: (E.g.) http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa_orm_1_0.xsd This schema extends http://java.sun.com/xml/ns/persistence/orm_1_0.xsd with OpenJPA specific stanza and uses the same name space as http://java.sun.com/xml/ns/persistence/orm; -- xsd:schema 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 xsd:annotation xsd:documentation @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 /xsd:documentation /xsd:annotation xsd:annotation xsd:documentation![CDATA[ This is the XML Schema for extending the persistence object-relational mapping file for OpenJPA specific features. The file may be named META-INF/orm.xml in the persistence archive or it may be named some other name which would be used to locate the file as resource on the classpath. ]]/xsd:documentation /xsd:annotation !-- Redefine the orm_1_0.xsd with additional OpenJPA extensions -- xsd:redefine schemaLocation=http://java.sun.com/xml/ns/persistence/orm_1_0.xsd !-- Append optional single data-cache element to entity. Valid values are true | false | 1 | 0. Default value is false. -- xsd:complexType name=entity xsd:complexContent xsd:extension base=orm:entity xsd:sequence xsd:element name=data-cache type=xsd:boolean minOccurs=0 maxOccurs=1 default=false/ /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType !-- Append optional single jdbc-nonpolymorphic element to one-to-many. Valid values are true | false | 1 | 0. Default value is false. Append optional single jdbc-eager-fetch-mode element to one-to-many. Valid values are parallel | others. Default value is parallel. -- xsd:complexType name=one-to-many xsd:complexContent xsd:extension base=orm:one-to-many xsd:sequence xsd:element name=jdbc-nonpolymorphic type=xsd:boolean minOccurs=0 maxOccurs=1 default=false/ xsd:element name=jdbc-eager-fetch-mode minOccurs=0 maxOccurs=1 default=parallel xsd:simpleType xsd:restriction base=xsd:string xsd:enumeration value=parallel/ xsd:enumeration value=others/ /xsd:restriction /xsd:simpleType /xsd:element /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType /xsd:redefine /xsd:schema Albert Lee
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. -- ?xml version=1.0 encoding=UTF-8? !-- OpenJPA specific orm.xml schema locates in: (E.g.) http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa _orm_1_0.xsd This schema extends http://java.sun.com/xml/ns/persistence/orm_1_0.xsd with OpenJPA specific stanza and uses the same name space as http://java.sun.com/xml/ns/persistence/orm; -- xsd:schema 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 xsd:annotation xsd:documentation @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 /xsd:documentation /xsd:annotation xsd:annotation xsd:documentation![CDATA[ This is the XML Schema for extending the persistence object-relational mapping file for OpenJPA specific features. The file may be named META-INF/orm.xml
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. -- ?xml version=1.0 encoding=UTF-8? !-- OpenJPA specific orm.xml schema locates in: (E.g.) http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa_orm_1_0.xsd; This schema extends http://java.sun.com/xml/ns/persistence/orm_1_0.xsdwith OpenJPA specific stanza and uses the same name space as http://java.sun.com/xml/ns/persistence/orm; -- xsd:schema 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 xsd:annotation xsd:documentation @(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007 /xsd:documentation /xsd:annotation xsd:annotation xsd:documentation![CDATA[ This is the XML Schema for extending the persistence object-relational mapping file for OpenJPA specific features. The file may be named META-INF/orm.xml in the persistence archive or it may be named some other name which would be used to locate the file as resource on the classpath. ]]/xsd:documentation /xsd:annotation !-- Redefine the orm_1_0.xsd with additional OpenJPA extensions -- xsd:redefine schemaLocation= http://java.sun.com/xml/ns/persistence/orm_1_0.xsd; !-- Append optional single data-cache element to entity. Valid values are true | false | 1 | 0. Default value is false. -- xsd:complexType name=entity xsd:complexContent xsd:extension base=orm:entity xsd:sequence xsd:element name=data-cache type=xsd:boolean minOccurs=0 maxOccurs=1 default=false/ /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType !-- Append optional single jdbc-nonpolymorphic element to one-to-many. Valid values are true | false | 1 | 0. Default value is false. Append optional single jdbc-eager-fetch-mode element to one-to-many. Valid values are parallel | others. Default value is parallel. -- xsd:complexType name=one-to-many xsd:complexContent xsd:extension base=orm:one-to-many xsd:sequence xsd:element name=jdbc-nonpolymorphic type=xsd:boolean minOccurs=0 maxOccurs=1 default=false/ xsd:element name=jdbc-eager-fetch-mode minOccurs=0 maxOccurs=1 default=parallel xsd:simpleType xsd:restriction base=xsd:string xsd:enumeration value=parallel/ xsd:enumeration value=others/ /xsd:restriction /xsd:simpleType /xsd:element /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType /xsd:redefine /xsd:schema Albert Lee
Re: Using query hints for mapping extensions in orm.xml
-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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). ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns= http://java.sun.com/xml/ns/ persistence/ orm version= 1.0 package org.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- named-query name= openjpa.extensions.Department !-- empty query element, since it is required -- query/ !-- class-level hints -- hint name=openjpa.data-cache value=false/ !-- hints for the employees field -- hint name=openjpa.employees.jdbc-eager-fetch - mode value=parallel/ hint name=openjpa.employees.jdbc- nonpolymorphic value=true/ /named-query !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ /one-to-many
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 openjpa:someelement 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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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
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 openjpa:someelement 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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/ orm version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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
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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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
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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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
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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch-mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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). ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- named-query name=openjpa.extensions.Department !-- empty query element, since
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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode 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 openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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
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...): ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 xmlns:openjpa=http://incubator.apache.org/openjpa/orm; packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- openjpa:data-cachefalse/openjpa:data-cache !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ !-- OpenJPA mapping extensions for the employees field -- openjpa:jdbc-eager-fetch-modeparallel/openjpa:jdbc-eager-fetch- mode openjpa:jdbc-nonpolymorphictrue/openjpa:jdbc-nonpolymorphic /one-to-many /attributes /entity /entity-mappings 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). ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/ orm version=1.0 packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA
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). ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- named-query name=openjpa.extensions.Department !-- empty query element, since it is required -- query/ !-- class-level hints -- hint name=openjpa.data-cache value=false/ !-- hints for the employees field -- hint name=openjpa.employees.jdbc-eager-fetch-mode value=parallel/ hint name=openjpa.employees.jdbc-nonpolymorphic value=true/ /named-query !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ /one-to-many /attributes /entity /entity-mappings
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). ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- named-query name=openjpa.extensions.Department !-- empty query element, since it is required -- query/ !-- class-level hints -- hint name=openjpa.data-cache value=false/ !-- hints for the employees field -- hint name=openjpa.employees.jdbc-eager-fetch-mode value=parallel/ hint name=openjpa.employees.jdbc-nonpolymorphic value=true/ /named-query !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ /one-to-many /attributes /entity /entity-mappings
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). ?xml version=1.0 encoding=UTF-8? entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; version=1.0 packageorg.apache.openjpa.mappingextensions/package entity name=Department class=Department table name=DEPARTMENT/ !-- OpenJPA mapping extensions for the Department entity -- named-query name=openjpa.extensions.Department !-- empty query element, since it is required -- query/ !-- class-level hints -- hint name=openjpa.data-cache value=false/ !-- hints for the employees field -- hint name=openjpa.employees.jdbc-eager-fetch-mode value=parallel/ hint name=openjpa.employees.jdbc-nonpolymorphic value=true/ /named-query !-- standard mappings follow -- attributes id name=id column name=ID/ /id basic name=name column name=NAME/ /basic one-to-many name=employees fetch=EAGER join-column name=FK_EMPS/ /one-to-many /attributes /entity /entity-mappings
