Do we have any experts with these xml namespaces? Or, anybody that wants to become an expert? :-) It seems like we need a real example of using these to make sure they are viable. On paper, they look like the solution. But, Craig's concern about allowing new member elements within existing elements is a valid question.
Any volunteers? Kevin On 1/16/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
That indeed does sound like a better solution. 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's > original 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> > > <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 of > this 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 the > way 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 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! >> >> >> >>
