I assume the test passed the <openjpa:someelement
someattribute="somevalue"/> uses
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings
version=" 1.0"
xmlns="http://java.sun.com/xml/ns/persistence/orm";
xmlns:openjpa=" http://incubator.apache.org/openjpa/orm";>
Since this header does not specify what schema to use, the openjpa
xml parser probably skipped the xml validation.
To enable xml validation the following header should be used:
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings
version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
xmlns="http://java.sun.com/xml/ns/persistence/orm";
xmlns:openjpa=" http://java.sun.com/xml/ns/persistence/orm";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd";
>
The orm_1_0.xsd does not recognize the new openjpa someelement stanza
and the xml validator will choke with an error/exception.
I have experimented a little with extending the orm_1_0.xsd schema
to accommodate possible openjpa specific stanza. Here are some
findings:
1) There are 2 forms of extensions:
a) add <xsd:any ..../> in various strategic locations in
orm_1_0.xsd to allow unspecified user free form extensions.
b) extends orm_1_0.xsd to openjpa specific schema (e.g.
openjpa_orm_1_0.xsd) using <xsd:redefine ..... />
2) The ideal solution is a) because this will allow providers to
correctly parse orm.xml with any extensions and ignore those
that it does not understand. Hence orm_1_0.xsd has already
casted in stone and any changes will have to wait until next
JPA version.
3) The next to ideal solution is b).
The advantage of this approach is one can naturally specify
provider specific stanza to the associated elements in orm.xml
(e.g. <entity>). The "redefine" of the schema is also pretty
straight forward to do.
The down side is the orm.xml has to specify the openjpa orm
schema instead of the standard orm_1_0.xsd. This will
potentially prohibit other providers not to accept the orm.xml.
Theoretically, provider should detect the schema used as
specified in "schemaLocation" in the header and parse the
orm.xml content accordingly. Not all providers are robust
enough to handle this properly.
I have attached a validated sample of the openjpa_orm_1_0.xsd
schema that accept 3 new openjpa specific stanza as described
in previous example and a validated sample of the instance of
the orm.xml document that uses the new schema. (Note One needs
to update the xsi:schemaLocation to point to an valid location
of openjpa_orm_1_0.xsd)
Albert Lee
On 1/22/07, Craig L Russell < [EMAIL PROTECTED]> wrote:
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 < [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!
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings
version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns="http://java.sun.com/xml/ns/persistence/orm";
xmlns:openjpa="http://java.sun.com/xml/ns/persistence/orm";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa_orm_1_0.xsd";
>
<package>org.apache.openjpa.mappingextensions</package>
<entity name="Department" class="Department">
<table name="DEPARTMENT"/>
<!-- 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-nonpolymorphic>true</openjpa:jdbc-nonpolymorphic>
<openjpa:jdbc-eager-fetch-mode>parallel</openjpa:jdbc-eager-fetch-mode>
</one-to-many>
</attributes>
<!-- OpenJPA mapping extensions for the Department entity -->
<openjpa:data-cache>false</openjpa:data-cache>
</entity>
</entity-mappings>
