Craig
On Jan 21, 2007, at 11:59 AM, Marc Prud'hommeaux wrote:
Not that I am volunteering to be the resident namespace expert, but FTR, I tried throwing in a <openjpa:someelement someattribute="somevalue"/> element into an orm.xml, and I notice that we don't complain when we parse it, so presumably at least our parse mode doesn't have any problem with it.Whether or not other implementations would be more restrictive is another issue...On Jan 18, 2007, at 6:16 AM, Kevin Sutter wrote:Do we have any experts with these xml namespaces? Or, anybody that wants tobecome 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! >> >> >> >>
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
