openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Using query hints for mapping extensions in orm.xml
Date Mon, 22 Jan 2007 06:07:01 GMT
If there is a way to include schema-validation="true" when parsing  
the orm, I expect that this will throw an exception.

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 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!
>>> >>
>>> >>
>>> >>
>>> >>
>>>
>>>
>

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