openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Using query hints for mapping extensions in orm.xml
Date Tue, 16 Jan 2007 02:47:59 GMT
Hi,

On Jan 15, 2007, at 5:12 PM, Patrick Linskey wrote:

> Hi,
>
> It kinda feels like we're corrupting the intended use of query hints.
> Plus, it seems unfortunate to have to drop back into untyped  
> strings if
> we can avoid it.
>
> I think that there is another approach that we've talked about  
> earlier:
> use namespaces to intersperse OpenJPA data into the orm.xml file.  
> That's
> my preferred solution.

Can you give an example of the usage in your scenario?

Thanks,

Craig

>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.
>
>> -----Original Message-----
>> From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On
>> Behalf Of Marc Prud'hommeaux
>> Sent: Monday, January 15, 2007 12:26 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Using query hints for mapping extensions in orm.xml
>>
>> OpenJPA people-
>>
>> A limitation of the JPA specification is that there is no built-in
>> way to put implementation-specific extensions in an orm.xml file,
>> which limits the use of OpenJPA's many useful extensions to only
>> being expressible annotations. Past suggestions for getting around
>> this limitation have been to alter the locally-cached version of the
>> XSD (which would make any orm.xml file that takes advantage of this
>> non-portable) or to have an additional file that contains the
>> extensions (e.g., an "openjpa-orm.xml" file peered with the
>> "orm.xml"
>> file).
>>
>> It just occurred to me that there is another possibility: the "hint"
>> child of the "named-query" element is a free-form field that acts as
>> a means to pass a query hint to the implementation. We could expand
>> on this to allow the passing of a mapping hint to the implementation
>> via a special-cased "openjpa.extensions.EntityName" named query in
>> which we could embed hints for the entity and its attributes.
>> See the
>> example below for how it might work.
>>
>> What do people think? It would allow us to keep the
>> extensions in the
>> same file in which the rest of the mappings are expressed, but still
>> remain portable to other JPA implementations (since other
>> implementations are supposed to ignore unrecognized query hints).
>>
>>
>>
>> <?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>
>>          </attributes>
>>      </entity>
>> </entity-mappings>
>>
>>
>>
>>
>>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message