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"> > <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> > > > > >
