openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Using query hints for mapping extensions in orm.xml
Date Thu, 18 Jan 2007 14:16:42 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message