openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Using query hints for mapping extensions in orm.xml
Date Thu, 18 Jan 2007 23:56:42 GMT
IIRC this sort of extension would only be allowed if the original  
schema "http://java.sun.com/xml/ns/persistence/orm" has explicitly  
allowed extension.  Historically, Sun has made it impossible to  
extend their xml documents.

-dain

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