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'soriginal 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";> <package>org.apache.openjpa.mappingextensions</package> <entity name="Department" class="Department"> <table name="DEPARTMENT"/> <!-- OpenJPA mapping extensions for the Department entity --> <openjpa:data-cache>false</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-mode>parallel</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-nonpolymorphic>true</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 ofthis 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 theway 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> >> </attributes> >> </entity> >> </entity-mappings> >> >> >> >> >> Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
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!
smime.p7s
Description: S/MIME cryptographic signature
