-----Original Message-----
From: Albert Lee [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 25, 2007 9:26 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Using query hints for mapping extensions in orm.xml
Let's put this into a more concrete terms:
Given:
1) Existing JPA orm schema in
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd
2) OpenJPA supports its version of the orm schema in
http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa
_orm_1_0.xsd
Note: we need to find a more permanent home for this
schema other
than putting it in incubator.apache.org. Suggestions?
3) xml name space for both schema are:
xmlns="http://java.sun.com/xml/ns/persistence/orm";
xmlns:openjpa="http://java.sun.com/xml/ns/persistence/orm";
Note: Both schema MUST be in the same name space due to schma
redefine restriction.
Use cases:
1) application specifies orm_1_0.xsd in the orm.xml
- portable to other providers
- no openjpa specific functions allow.
2) application specifies openjpa_orm_1_0.xsd in orm.xml
- only "guarantee" to work with openjpa provider.
- openjpa functions must be specified according to openjpa orm
additional schema.
- Can use the combination of persistence.xml <provider> and
orm.xml<entity-mappings xsi:schemaLocation=..openjpa_orm_1_0.xsd>
stanza to enforce
the orm must be applied using openjpa provider.
persistence.xml
<persistence ....... >
<persistence-unit name="MyEmployeePU">
<provider>
org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<mapping-file>META-INF/openjpa_orm.xml</mapping-file>
......
openjpa_orm.xml
<entity-mappings .....
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence/orm
http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa
_orm_1_0.xsd">
........
3) No schema is specified in the orm.xml (least desirable option)
- openjpa functions may be added to orm.xml. OpenJPA
tolerates this
option
- There is no validation on the stanza, hence may be
problematic in
processing/handling of the stanza.
- No guarantee this will work in other providers.
- But this option is the least restrictive in orm usage
All three options are available for use by an application, in
order of
compliance and portability preferences.
Albert Lee.
On 1/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
Firstly, thanks for putting this together.
I don't think that portability is a huge problem. I agree
with the three
scenarios that Albert mentioned, but I think that we can refine #1:
1) if an application wants to be fully portable between
providers, the
standard orm.xsd must be specified. This will inhibit the use
of openjpa
features.
I would revise this as follows:
1) if an application wants to be fully portable between
providers, the
standard orm.xsd must be specified. This will inhibit the
use of OpenJPA
features in that file, so a parallel openjpa-orm.xml file
must be used
which conforms to the OpenJPA XSD and adds the additional
information.
We could even create a second XSD for that situation that
allows only
OpenJPA content to help prevent people from putting
conflicting stanzas
in the two files.
-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: Albert Lee [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 24, 2007 8:38 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Using query hints for mapping extensions in orm.xml
First, I would not expected other providers will handle
the special
openjpa.orm.xsd even if it is spec'ed out in the document
header. If they
choose to ignore the new schema and proceed to parse the
document content
using the standard orm.xsd, then any openjpa specific stanza
will probably
be flagged as non-compliance.
The other scenario is: what about if the document does
not specify the
schema at all, like the original sample. I suspect most
providers will
tolerate this scenario, just like openjpa does.
Can the solutions be:
1) if an application wants to be fully portable between
providers, the
standard orm.xsd must be specified. This will inhibit the use
of openjpa
features.
2) if an application wants to use openjpa specific stanza and
still be used
by other provider, don't specify the schema at all in the
document. Hoping
the other providers will tolerate and ignore the openjpa features.
3) if an application wants to be openjpa schema
compliance, then use
openjpa.orm.xsd in the document header and openjpa can
validate the
document. However this will prevent the application to be
portable to other
providers.
Albert Lee.
On 1/24/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:
Thank you, Albert, for your experimentation. The updated schema
definition
(openjpa_orm_1_0.xsd) and the example openjpa_orm.xml seems
to be what we
are looking for. I guess the only concern is whether we
can count on
other
JPA implementations to ignore this extra schema definition
and just rely
on
the standard orm.xsd.
Question: Even if other JPA providers are smart enough to
ignore our
specialized schema and use the standard JPA schema, what
happens to our
extension elements? Do they get ignored as well? Or, will the
verification
step still trip over these new/updated elements?
Thanks again,
Kevin
On 1/23/07, Albert Lee <[EMAIL PROTECTED]> wrote:
Somehow the one of the attachment (openjpa_orm_1_0.xsd)
from my previous
note did not make it to this forum.
Try again here.
--------------------------------------------------------------
--------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!--
OpenJPA specific orm.xml schema locates in: (E.g.)
http://incubator.apache.org/openjpa/xml/ns/persistence/openjpa
_orm_1_0.xsd
"
This schema extends
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd
with
OpenJPA specific stanza and uses the same
name space as
"http://java.sun.com/xml/ns/persistence/orm";
-->
<xsd:schema
version="1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
targetNamespace="
http://java.sun.com/xml/ns/persistence/orm";
xmlns:orm="http://java.sun.com/xml/ns/persistence/orm";
elementFormDefault="qualified"
attributeFormDefault="unqualified"
<xsd:annotation>
<xsd:documentation>
@(#)openjpa_orm_1_0.xsd 1.0 Jan 22 2007
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation><![CDATA[
This is the XML Schema for extending the persistence
object-relational
mapping file for OpenJPA specific features.
The file may be named "META-INF/orm.xml" in
the persistence
archive or it may be named some other name
which would be
used to locate the file as resource on the classpath.
]]></xsd:documentation>
</xsd:annotation>
<!-- Redefine the orm_1_0.xsd with additional OpenJPA
extensions -->
<xsd:redefine schemaLocation="
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd
">
<!--
Append optional single <data-cache> element
to <entity>.
Valid values are "true" | "false" | "1" | "0".
Default value is "false".
-->
<xsd:complexType name="entity">
<xsd:complexContent>
<xsd:extension base="orm:entity">
<xsd:sequence>
<xsd:element name="data-cache" type="xsd:boolean"
minOccurs="0" maxOccurs="1" default="false"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
Append optional single <jdbc-nonpolymorphic>
element to
<one-to-many>.
Valid values are "true" | "false" | "1" | "0".
Default value is "false".
Append optional single
<jdbc-eager-fetch-mode> element to
<one-to-many>.
Valid values are "parallel" | "others".
Default value is "parallel".
-->
<xsd:complexType name="one-to-many">
<xsd:complexContent>
<xsd:extension base="orm:one-to-many">
<xsd:sequence>
<xsd:element name="jdbc-nonpolymorphic"
type="xsd:boolean"
minOccurs="0" maxOccurs="1" default="false"/>
<xsd:element name="jdbc-eager-fetch-mode"
minOccurs="0"
maxOccurs="1" default="parallel">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="parallel"/>
<xsd:enumeration value="others"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:redefine>
</xsd:schema>
Albert Lee
