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>
>> </attributes>
>> </entity>
>> </entity-mappings>
>>
>>
>>
>>
>>
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!