openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Using query hints for mapping extensions in orm.xml
Date Sun, 21 Jan 2007 19:59:42 GMT


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 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 <mprudhom@apache.org> 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 <Craig.Russell@sun.com> 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:mprudhomapache@gmail.com] 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:Craig.Russell@sun.com
>> >> P.S. A good JDO? O, Gasp!
>> >>
>> >>
>> >>
>> >>
>>
>>


Mime
View raw message