openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Parry <qeldr...@gmail.com>
Subject Re: Using query hints for mapping extensions in orm.xml
Date Thu, 05 Apr 2007 20:12:39 GMT
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:allee8285@gmail.com]
>> 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.xml<entity-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-file>META-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 <plinskey@bea.com> 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:allee8285@gmail.com]
>>>> 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 <kwsutter@gmail.com> 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 <allee8285@gmail.com> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>


Mime
View raw message