You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Pinaki Poddar <pp...@bea.com> on 2007/07/27 18:32:16 UTC
Persistence of Service Data Objects using OpenJPA
Hi Frank,
Thank you for your interest. Before I answer the specific questions
let me say few words to explain why Fluid is attempted at first place.
A) there is a natural synergy between SDO model and the POJO model
where JPA excels.
B) Object Persistence (be it strongly-typed POJO or loosely-typed
SDO) is complex problem by itself. Throw in quirk of multiple database
vendors -- and one really got a hard problem in hand. OpenJPA,
Hibernate, TopLink had worked over many years to solve this problem to a
reasonable degree. SDO persistence should leverage that knowledge/effort
instead of reinventing a costly wheel.
1) Yes -- you're right. The views expressed in
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29 is in agreement with what promoted me to start the lab
(actually I checked this page while researching and mentioned in in my
blog). According to this wiki page: "Work on the specification of a JPA
data access service by the OSOA collaboration is envisaged sometime in
the future but has not started yet."
So Fluid can be considered as a prototype/exploration of similar
ideas.
2) Yes, I am aware of SDO's generation of Java and I have played with
org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to
write yet another code generator for Fluid because
a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type
information defined by XSDHelper.define().
The annotations in the class will be made optional as we proceed --
because JPA allows a separate mapping file
Orm.xml thereby retaining POJO-ness of the persistent domain classes.
b) The generated Java classes is "domain-ready" i.e. they are
self-consistent and independent. Proof: they can
be compiled without any other package other that java.util.*. Adding
annotation, however, makes them compile-dependent on jpa.jar, but that
dependency will be made optional as mapping information can be
externalized in orm.xml.
C) as far as SDO metamodel to Java metamodel mapping goes, it is
essentially isomorphic (at least for this prototype).
SDO2POJO does not introduce any extra artifact (see below). I have not
played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to
make a fair judgement -- but most probably it is generating Java classes
which has more dependency on framework classes in terms of
(inheriting/implementing) as well as package imports.
d) One mapping element is introduced in SDO-Java conversion process.
It is about "Container" SDO Types. I describe the details in Fluid
website. The reason for defining a Container Type abstraction is better
alignment for mapping to relational database (save extra joins and allow
navigational query across multi-cardinality relation paths).
3) Besides the source code generation route, another possibilities is
dynamic Java bytecode generation for SDO Types. Fluid prototyped that
approach too.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 10:39 AM
To: tuscany-dev@ws.apache.org
Subject: RE: How does xsd:ID property type is distinguished from
xsd:string
Hi Pinaki,
This looks very cool, especially that you've got a working prototype! I
have a couple of questions.
1) This seems to overlap with the DAS plan described here:
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29
I'm not very familiar with the DAS work myself, but there seems to be
some overlap with your work.
2) I'm also wondering if you were aware that SDO also defines a mapping
to static Java interfaces/classes. See section 5 of the SDO spec:
http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p
df?version=1
Does your SDO2POJOGenerator conform to that mapping? Have you tried the
Tuscany static SDO generator
(org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
relashionship?
Frank.
"Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> Hello,
> I have been asking newbie questions to this forum. And people have
> been very helpful.
>
> Those newbie questions were for a Apache Lab project named Fluid --
> to explore possibilities of SDO persistence using JPA API.
>
> With all your help, I could put together an initial proptotype that
> creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA
> for SDO and JPA implementation respectively.
>
> Further details of this project (with user documentation) can be
> found at
>
> http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> Your comments/suggestions are most welcome --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Tuesday, July 24, 2007 4:59 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> EAttribute.isID() will only be true if the type is xsd:ID.
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
>
> > Hi Frank,
> > > Database IDs (e.g., primary and foreign keys) are more related
> > to
>
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Thanks for telling me this.
> >
> > Now is ((property.getType().isDataType()) &&
> > ((EAttribute)property).isID())) == true for a property p that is
> > declared as xsd:key or xsd:keyref?
> >
> > Or broadly, what is the semantics of Eattribute.isID()?
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 3:01 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > Identity support is also in the SDO 3 charter: Support for a concept
> > of identity in SDO, and its relationship to other technologies.
> >
> > Database IDs (e.g., primary and foreign keys) are more related to
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> >
> > > Hi Frank,
> > > Thanks.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > >
> > > That is good news. However, identity mechanics should appear
> > > more distinctly on API surface e.g.
> > > boolean Proprty.isIdentifier();
> > > List<Property> Type.getIdentifiers();
> > >
> > > I will qualify absence of any identity semantics from SDO a major
> > > drawback. Especially, if it comes to any persistence operation on
> > > SDO DataObject/DataGraph. Hopefully some of the SDO spec writers
> > > would notice this omission and add it to future spec version.
> > >
> > > After a quick pick in current DAS implementation, it appeared that
> > > 'primary key' identification is based on existing database column
> > > name
> >
> > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to learn
> > > how DAS is handling identity issue.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > > That is a good decision. Wrapping should always provide access to
> > > what
> >
> > > is being wrapped.
> > >
> > > > downcasting to the EMF implementation class
> > >
> > > Thanks for this info. I will do this for now. But I heed your
> > > advice
>
> > > and have already a scheme in place that programs against *only*
> > > commonj.sdo API but can access underlying implementaion, if
> > > available,
> >
> > > without any compile-time binding.
> > > Slightly costly -- but works for, say, extracting package name
> > > from Types.
> > >
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > They can't be distinguished in the current version of SDO
> > > metadata, you need to look at the original XSD. The next version
> > > of SDO (SDO
> > > 3) is planning to provide an api for accessing extended XSD
> > > metadata. In Tuscany, you can currently determine this by
> > > downcasting to the EMF implementation class, although we don't
> recommend people do that:
> > >
> > > System.out.println(" Property isID: " +
> > > ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID()));
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03 AM:
> > >
> > > >
> > > > Hi,
> > > >
> > > > A newbie question:
> > > > How does two Property: one defined as xsd:string and other as
> > > > xsd:ID can be distiguished?
> > > >
> > > > Assume:
> > > > 1. we have a simple XML schema defining a Person SDO Type with
> > > > two properties as follows:
> > > > <xsd:complexType name="Person">
> > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > </xsd:complexType>
> > > >
> > > > 2. TypeHelper.INSTANCE.define()
> > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > firstName)
> > >
> > > > and p2 (for id)
> > > >
> > > > 3. both p1.getType().getInstanceClass() and
> > > > p2.getType().getInstanceClass() return java.lang.String
> > > > both p1.getType().isDataType() and p2.getType().isDataType()
> > > > return true
> > > >
> > > > The question is, what can be done to identify p2 as a property
> > > > that were defined as xsd:ID?
> > > >
> > > >
> > > > Thanks for your help --
> > > >
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Persistence of Service Data Objects using OpenJPA
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Frank,
> I think your project has a lot of potential.
Thank you for your encouraging words.
> JAXB with static SDO in version 3. JAXB2, as you may know, has a
similar objective to support standard POJOs.
> If that happens, then I see even more synergy with your approach.
Yes -- though Fluid only begins with SDO -- but the idea is to explore
extending OpenJPA (that is originally designed to handle strongly-typed
meta systems) for relaxed-type meta systsms. So that SDO, XML document
and data from other loosely-typed systems can leverage significant
features of JPA. This brings us to the question:
How the "other" type system is mapped to strongly-typed Java domain
that JPA can handle?
The mechanics of such mapping can be delegated to JAXB provided it
does not introduce its own artifact in the generation process. Because
the target domain object that JPA will handle is better to be POJO
(restoring that POJO nature from under heavyweight EJB framework had
been a long battle :).
Fluid prototype skips the question by degenarting SDO-Java mapping to
isomorphic case and writing a SDO2POJOGenerator in few lines.
> At Tuscany, we'd also be very interested in the bytecode generation
that you mentioned you've prototyped in Fluid. Tuscany has done a little
bit of sandbox prototyping in that area as well, but nobody has had
enough time to really pursue it.
Bytecode generation is feasible, powerful and difficult to maintain.
OpenJPA uses bytecode generation with SERP (http://serp.sourceforge.net/
written by one of the architects of OpenJPA) library extensively as a
post-compilation process known as enhancement. Powerful and neat it is,
but, enhanement has often been seen as 'barrier-to-entry' by the
critics.
Moreover, from O-O mapping standpoint -- an intermediate Java source
code + plus a mapping specs is perhaps a more maintainable and
comprehensible route than magical, dynamic bytecode generation.
In Fluid source codebase org.apache.openjpa.sdo.SDOTypeRepostory has
the bytecode generation code. It is not activated though.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 2:59 PM
To: tuscany-dev@ws.apache.org
Cc: dev@openjpa.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA
Hi Pinaki,
I think your project has a lot of potential. Another related aspect is
that there is interest in the SDO specification charter to discuss the
possibility of converging/supporting JAXB with static SDO in version 3.
JAXB2, as you may know, has a similar objective to support standard
POJOs.
If that happens, then I see even more synergy with your approach. At
Tuscany, we'd also be very interested in the bytecode generation that
you mentioned you've prototyped in Fluid. Tuscany has done a little bit
of sandbox prototyping in that area as well, but nobody has had enough
time to really pursue it.
Given this work, I think you should consider getting involved with the
DAS specification effort, if you haven't already.
Frank.
"Pinaki Poddar" <pp...@bea.com>
07/27/2007 12:32 PM
Please respond to
tuscany-dev@ws.apache.org
To
<tu...@ws.apache.org>
cc
<de...@openjpa.apache.org>
Subject
Persistence of Service Data Objects using OpenJPA
Hi Frank,
Thank you for your interest. Before I answer the specific questions
let me say few words to explain why Fluid is attempted at first place.
A) there is a natural synergy between SDO model and the POJO model
where JPA excels.
B) Object Persistence (be it strongly-typed POJO or loosely-typed
SDO) is complex problem by itself. Throw in quirk of multiple database
vendors -- and one really got a hard problem in hand. OpenJPA,
Hibernate, TopLink had worked over many years to solve this problem to a
reasonable degree. SDO persistence should leverage that knowledge/effort
instead of reinventing a costly wheel.
1) Yes -- you're right. The views expressed in
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29 is in agreement with what promoted me to start the lab
(actually I checked this page while researching and mentioned in in my
blog). According to this wiki page: "Work on the specification of a JPA
data access service by the OSOA collaboration is envisaged sometime in
the future but has not started yet."
So Fluid can be considered as a prototype/exploration of similar
ideas.
2) Yes, I am aware of SDO's generation of Java and I have played with
org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to
write yet another code generator for Fluid because
a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type
information defined by XSDHelper.define().
The annotations in the class will be made optional as we proceed --
because JPA allows a separate mapping file
Orm.xml thereby retaining POJO-ness of the persistent domain classes.
b) The generated Java classes is "domain-ready" i.e. they are
self-consistent and independent. Proof: they can
be compiled without any other package other that java.util.*. Adding
annotation, however, makes them compile-dependent on jpa.jar, but that
dependency will be made optional as mapping information can be
externalized in orm.xml.
C) as far as SDO metamodel to Java metamodel mapping goes, it is
essentially isomorphic (at least for this prototype).
SDO2POJO does not introduce any extra artifact (see below). I have not
played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to
make a fair judgement -- but most probably it is generating Java classes
which has more dependency on framework classes in terms of
(inheriting/implementing) as well as package imports.
d) One mapping element is introduced in SDO-Java conversion process.
It is about "Container" SDO Types. I describe the details in Fluid
website. The reason for defining a Container Type abstraction is better
alignment for mapping to relational database (save extra joins and allow
navigational query across multi-cardinality relation paths).
3) Besides the source code generation route, another possibilities is
dynamic Java bytecode generation for SDO Types. Fluid prototyped that
approach too.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 10:39 AM
To: tuscany-dev@ws.apache.org
Subject: RE: How does xsd:ID property type is distinguished from
xsd:string
Hi Pinaki,
This looks very cool, especially that you've got a working prototype! I
have a couple of questions.
1) This seems to overlap with the DAS plan described here:
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29
I'm not very familiar with the DAS work myself, but there seems to be
some overlap with your work.
2) I'm also wondering if you were aware that SDO also defines a mapping
to static Java interfaces/classes. See section 5 of the SDO spec:
http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p
df?version=1
Does your SDO2POJOGenerator conform to that mapping? Have you tried the
Tuscany static SDO generator
(org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
relashionship?
Frank.
"Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> Hello,
> I have been asking newbie questions to this forum. And people have
> been very helpful.
>
> Those newbie questions were for a Apache Lab project named Fluid --
> to explore possibilities of SDO persistence using JPA API.
>
> With all your help, I could put together an initial proptotype that
> creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA
> for SDO and JPA implementation respectively.
>
> Further details of this project (with user documentation) can be
> found at
>
> http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> Your comments/suggestions are most welcome --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Tuesday, July 24, 2007 4:59 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> EAttribute.isID() will only be true if the type is xsd:ID.
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
>
> > Hi Frank,
> > > Database IDs (e.g., primary and foreign keys) are more related
> > to
>
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Thanks for telling me this.
> >
> > Now is ((property.getType().isDataType()) &&
> > ((EAttribute)property).isID())) == true for a property p that is
> > declared as xsd:key or xsd:keyref?
> >
> > Or broadly, what is the semantics of Eattribute.isID()?
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 3:01 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > Identity support is also in the SDO 3 charter: Support for a concept
> > of identity in SDO, and its relationship to other technologies.
> >
> > Database IDs (e.g., primary and foreign keys) are more related to
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> >
> > > Hi Frank,
> > > Thanks.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > >
> > > That is good news. However, identity mechanics should appear
> > > more distinctly on API surface e.g.
> > > boolean Proprty.isIdentifier();
> > > List<Property> Type.getIdentifiers();
> > >
> > > I will qualify absence of any identity semantics from SDO a major
> > > drawback. Especially, if it comes to any persistence operation on
> > > SDO DataObject/DataGraph. Hopefully some of the SDO spec writers
> > > would notice this omission and add it to future spec version.
> > >
> > > After a quick pick in current DAS implementation, it appeared that
> > > 'primary key' identification is based on existing database column
> > > name
> >
> > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to learn
> > > how DAS is handling identity issue.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > > That is a good decision. Wrapping should always provide access to
> > > what
> >
> > > is being wrapped.
> > >
> > > > downcasting to the EMF implementation class
> > >
> > > Thanks for this info. I will do this for now. But I heed your
> > > advice
>
> > > and have already a scheme in place that programs against *only*
> > > commonj.sdo API but can access underlying implementaion, if
> > > available,
> >
> > > without any compile-time binding.
> > > Slightly costly -- but works for, say, extracting package name
> > > from Types.
> > >
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > They can't be distinguished in the current version of SDO
> > > metadata, you need to look at the original XSD. The next version
> > > of SDO (SDO
> > > 3) is planning to provide an api for accessing extended XSD
> > > metadata. In Tuscany, you can currently determine this by
> > > downcasting to the EMF implementation class, although we don't
> recommend people do that:
> > >
> > > System.out.println(" Property isID: " +
> > > ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID()));
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03 AM:
> > >
> > > >
> > > > Hi,
> > > >
> > > > A newbie question:
> > > > How does two Property: one defined as xsd:string and other as
> > > > xsd:ID can be distiguished?
> > > >
> > > > Assume:
> > > > 1. we have a simple XML schema defining a Person SDO Type with
> > > > two properties as follows:
> > > > <xsd:complexType name="Person">
> > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > </xsd:complexType>
> > > >
> > > > 2. TypeHelper.INSTANCE.define()
> > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > firstName)
> > >
> > > > and p2 (for id)
> > > >
> > > > 3. both p1.getType().getInstanceClass() and
> > > > p2.getType().getInstanceClass() return java.lang.String
> > > > both p1.getType().isDataType() and p2.getType().isDataType()
> > > > return true
> > > >
> > > > The question is, what can be done to identify p2 as a property
> > > > that were defined as xsd:ID?
> > > >
> > > >
> > > > Thanks for your help --
> > > >
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Persistence of Service Data Objects using OpenJPA
Posted by Pinaki Poddar <pp...@bea.com>.
Hello Luciano,
>> I haven't looked into this with any great detail,
Thank you for your interest.
The idea of Fluid is to keep it simple and use standard API contracts
-- so there is not much detail to look at:)
Just download (it is order of 100KB) and run. Or browse the test cases
to see how it is being used.
>> but I'd like to ask if would be feasible to add a DAS interface[1]
layer on top of Fluid [2].
I have briefly looked at DAS and saw it using a Command Object
pattern. That kind of interface is generic enough to put on top of
almost anything -- so broadly speaking -- answer to your question is:
Yes.
What worried me about DAS is its SQL-bias as expressed in methods like:
Command createCommand(String sql);
Notionally, JPA and object persistence layer prefers to operate on an
"Object View" -- the view being the Java domain model -- while actual
model is "database schema". The promise of JPA is to allow this
"updatable object view" of relational tables to the user.
Shooting direct SQL from user application breaks that notion (though due
to public demand, JPA spec allows SQL to be executed on the side -- but
that is not kosher)
It is also important to note at this point that a robust persistence
mechanism that supports disconnect application programming model must
require the domain objects to carry two important bits of information:
identity & version. SDO Spec is silent about these aspects at this
moment -- but may be future versions will pay attention to such details.
I have asked the question on identity scheme used by current DAS
implementation (but did not get an answer). Fluid
makes some convention which can be questioned but they are clearly spelt
out. Anyway, these restrictions are planned to relaxed.
My comments against each of the DAS API method follow:
interface DAS {
// This will become merge() in JPA - very doable
void applyChanges(DataObject root);
// Possible to commandify JPA EntityManager API: Persist, Update,
Query, Find, Remove
Command getCommand(String name);
// Not good: may be with some restriction
Command createCommand(String sql);
// Yes
void releaseResources();
}
public interface Command {
// Depends what commands are served by DAS
void execute();
// Possible the result should be List<DataObject> rather than
DataObject so that one can iterate for large returns
DataObject executeQuery();
// Again very SQL centric and will work for restricted cases where
command is Query
void setParameter(int index, Object value);
Object getParameter(int index);
// This will work with very restricted sense of identity. JPA has
more powerful feature of identity
// which Fluid has only partially exposed
int getGeneratedKey();
}
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Friday, July 27, 2007 3:25 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA
I haven't looked into this with any great detail, but I'd like to ask if
would be feasible to add a DAS interface[1] layer on top of Fluid [2].
Thoughts ?
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main
/java/org/apache/tuscany/das/rdb/DAS.java
[2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> Hi Pinaki,
>
> I think your project has a lot of potential. Another related aspect is
> that there is interest in the SDO specification charter to discuss the
> possibility of converging/supporting JAXB with static SDO in version
3.
> JAXB2, as you may know, has a similar objective to support standard
POJOs.
> If that happens, then I see even more synergy with your approach. At
> Tuscany, we'd also be very interested in the bytecode generation that
> you mentioned you've prototyped in Fluid. Tuscany has done a little
> bit of sandbox prototyping in that area as well, but nobody has had
> enough time to really pursue it.
>
> Given this work, I think you should consider getting involved with the
> DAS specification effort, if you haven't already.
>
> Frank.
>
>
>
>
> "Pinaki Poddar" <pp...@bea.com>
> 07/27/2007 12:32 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
> <de...@openjpa.apache.org>
> Subject
> Persistence of Service Data Objects using OpenJPA
>
>
>
>
>
>
> Hi Frank,
>
> Thank you for your interest. Before I answer the specific questions
> let me say few words to explain why Fluid is attempted at first place.
>
> A) there is a natural synergy between SDO model and the POJO model
> where JPA excels.
> B) Object Persistence (be it strongly-typed POJO or loosely-typed
> SDO) is complex problem by itself. Throw in quirk of multiple database
> vendors -- and one really got a hard problem in hand. OpenJPA,
> Hibernate, TopLink had worked over many years to solve this problem to
> a reasonable degree. SDO persistence should leverage that
> knowledge/effort instead of reinventing a costly wheel.
>
>
> 1) Yes -- you're right. The views expressed in
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29 is in agreement with what promoted me to start the lab
> (actually I checked this page while researching and mentioned in in my
> blog). According to this wiki page: "Work on the specification of a
> JPA data access service by the OSOA collaboration is envisaged
> sometime in the future but has not started yet."
> So Fluid can be considered as a prototype/exploration of similar
> ideas.
>
> 2) Yes, I am aware of SDO's generation of Java and I have played with
> org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided
> to write yet another code generator for Fluid because
>
> a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> Type information defined by XSDHelper.define().
> The annotations in the class will be made optional as we proceed --
> because JPA allows a separate mapping file Orm.xml thereby retaining
> POJO-ness of the persistent domain classes.
>
> b) The generated Java classes is "domain-ready" i.e. they are
> self-consistent and independent. Proof: they can be compiled without
> any other package other that java.util.*. Adding annotation, however,
> makes them compile-dependent on jpa.jar, but that dependency will be
> made optional as mapping information can be externalized in orm.xml.
>
> C) as far as SDO metamodel to Java metamodel mapping goes, it is
> essentially isomorphic (at least for this prototype).
> SDO2POJO does not introduce any extra artifact (see below). I have not
> played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> to make a fair judgement -- but most probably it is generating Java
> classes which has more dependency on framework classes in terms of
> (inheriting/implementing) as well as package imports.
>
> d) One mapping element is introduced in SDO-Java conversion
process.
> It is about "Container" SDO Types. I describe the details in Fluid
> website. The reason for defining a Container Type abstraction is
> better alignment for mapping to relational database (save extra joins
> and allow navigational query across multi-cardinality relation paths).
>
>
> 3) Besides the source code generation route, another possibilities
> is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> that approach too.
>
> Regards --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Friday, July 27, 2007 10:39 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> Hi Pinaki,
>
> This looks very cool, especially that you've got a working prototype!
> I have a couple of questions.
>
> 1) This seems to overlap with the DAS plan described here:
>
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29
>
> I'm not very familiar with the DAS work myself, but there seems to be
> some overlap with your work.
>
> 2) I'm also wondering if you were aware that SDO also defines a
> mapping to static Java interfaces/classes. See section 5 of the SDO
spec:
>
>
> http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL
> .p
> df?version=1
>
> Does your SDO2POJOGenerator conform to that mapping? Have you tried
> the Tuscany static SDO generator
> (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> relashionship?
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
>
> > Hello,
> > I have been asking newbie questions to this forum. And people have
> > been very helpful.
> >
> > Those newbie questions were for a Apache Lab project named Fluid
> > -- to explore possibilities of SDO persistence using JPA API.
> >
> > With all your help, I could put together an initial proptotype
> > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > OpenJPA for SDO and JPA implementation respectively.
> >
> > Further details of this project (with user documentation) can be
> > found at
> >
> > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> >
> > Your comments/suggestions are most welcome --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 4:59 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > EAttribute.isID() will only be true if the type is xsd:ID.
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> >
> > > Hi Frank,
> > > > Database IDs (e.g., primary and foreign keys) are more
> > > related to
> >
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Thanks for telling me this.
> > >
> > > Now is ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID())) == true for a property p that is
> > > declared as xsd:key or xsd:keyref?
> > >
> > > Or broadly, what is the semantics of Eattribute.isID()?
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > Identity support is also in the SDO 3 charter: Support for a
> > > concept
>
> > > of identity in SDO, and its relationship to other technologies.
> > >
> > > Database IDs (e.g., primary and foreign keys) are more related to
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > >
> > > > Hi Frank,
> > > > Thanks.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > >
> > > > That is good news. However, identity mechanics should appear
> > > > more distinctly on API surface e.g.
> > > > boolean Proprty.isIdentifier();
> > > > List<Property> Type.getIdentifiers();
> > > >
> > > > I will qualify absence of any identity semantics from SDO a
> > > > major drawback. Especially, if it comes to any persistence
> > > > operation on SDO DataObject/DataGraph. Hopefully some of the SDO
> > > > spec writers would notice this omission and add it to future
spec version.
> > > >
> > > > After a quick pick in current DAS implementation, it appeared
> > > > that
>
> > > > 'primary key' identification is based on existing database
> > > > column name
> > >
> > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > learn how DAS is handling identity issue.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > > That is a good decision. Wrapping should always provide access
> > > > to what
> > >
> > > > is being wrapped.
> > > >
> > > > > downcasting to the EMF implementation class
> > > >
> > > > Thanks for this info. I will do this for now. But I heed your
> > > > advice
> >
> > > > and have already a scheme in place that programs against *only*
> > > > commonj.sdo API but can access underlying implementaion, if
> > > > available,
> > >
> > > > without any compile-time binding.
> > > > Slightly costly -- but works for, say, extracting package name
> > > > from Types.
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > They can't be distinguished in the current version of SDO
> > > > metadata, you need to look at the original XSD. The next version
> > > > of SDO (SDO
> > > > 3) is planning to provide an api for accessing extended XSD
> > > > metadata. In Tuscany, you can currently determine this by
> > > > downcasting to the EMF implementation class, although we don't
> > recommend people do that:
> > > >
> > > > System.out.println(" Property isID: " +
> > > > ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID()));
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
AM:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > A newbie question:
> > > > > How does two Property: one defined as xsd:string and other
> > > > > as
>
> > > > > xsd:ID can be distiguished?
> > > > >
> > > > > Assume:
> > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > with two properties as follows:
> > > > > <xsd:complexType name="Person">
> > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > 2. TypeHelper.INSTANCE.define()
> > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > firstName)
> > > >
> > > > > and p2 (for id)
> > > > >
> > > > > 3. both p1.getType().getInstanceClass() and
> > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > both p1.getType().isDataType() and
> > > > > p2.getType().isDataType()
>
> > > > > return true
> > > > >
> > > > > The question is, what can be done to identify p2 as a property
> > > > > that were defined as xsd:ID?
> > > > >
> > > > >
> > > > > Thanks for your help --
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > 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.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
RE: Persistence of Service Data Objects using OpenJPA
Posted by Pinaki Poddar <pp...@bea.com>.
Hello Luciano,
>> I haven't looked into this with any great detail,
Thank you for your interest.
The idea of Fluid is to keep it simple and use standard API contracts
-- so there is not much detail to look at:)
Just download (it is order of 100KB) and run. Or browse the test cases
to see how it is being used.
>> but I'd like to ask if would be feasible to add a DAS interface[1]
layer on top of Fluid [2].
I have briefly looked at DAS and saw it using a Command Object
pattern. That kind of interface is generic enough to put on top of
almost anything -- so broadly speaking -- answer to your question is:
Yes.
What worried me about DAS is its SQL-bias as expressed in methods like:
Command createCommand(String sql);
Notionally, JPA and object persistence layer prefers to operate on an
"Object View" -- the view being the Java domain model -- while actual
model is "database schema". The promise of JPA is to allow this
"updatable object view" of relational tables to the user.
Shooting direct SQL from user application breaks that notion (though due
to public demand, JPA spec allows SQL to be executed on the side -- but
that is not kosher)
It is also important to note at this point that a robust persistence
mechanism that supports disconnect application programming model must
require the domain objects to carry two important bits of information:
identity & version. SDO Spec is silent about these aspects at this
moment -- but may be future versions will pay attention to such details.
I have asked the question on identity scheme used by current DAS
implementation (but did not get an answer). Fluid
makes some convention which can be questioned but they are clearly spelt
out. Anyway, these restrictions are planned to relaxed.
My comments against each of the DAS API method follow:
interface DAS {
// This will become merge() in JPA - very doable
void applyChanges(DataObject root);
// Possible to commandify JPA EntityManager API: Persist, Update,
Query, Find, Remove
Command getCommand(String name);
// Not good: may be with some restriction
Command createCommand(String sql);
// Yes
void releaseResources();
}
public interface Command {
// Depends what commands are served by DAS
void execute();
// Possible the result should be List<DataObject> rather than
DataObject so that one can iterate for large returns
DataObject executeQuery();
// Again very SQL centric and will work for restricted cases where
command is Query
void setParameter(int index, Object value);
Object getParameter(int index);
// This will work with very restricted sense of identity. JPA has
more powerful feature of identity
// which Fluid has only partially exposed
int getGeneratedKey();
}
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Friday, July 27, 2007 3:25 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA
I haven't looked into this with any great detail, but I'd like to ask if
would be feasible to add a DAS interface[1] layer on top of Fluid [2].
Thoughts ?
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main
/java/org/apache/tuscany/das/rdb/DAS.java
[2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> Hi Pinaki,
>
> I think your project has a lot of potential. Another related aspect is
> that there is interest in the SDO specification charter to discuss the
> possibility of converging/supporting JAXB with static SDO in version
3.
> JAXB2, as you may know, has a similar objective to support standard
POJOs.
> If that happens, then I see even more synergy with your approach. At
> Tuscany, we'd also be very interested in the bytecode generation that
> you mentioned you've prototyped in Fluid. Tuscany has done a little
> bit of sandbox prototyping in that area as well, but nobody has had
> enough time to really pursue it.
>
> Given this work, I think you should consider getting involved with the
> DAS specification effort, if you haven't already.
>
> Frank.
>
>
>
>
> "Pinaki Poddar" <pp...@bea.com>
> 07/27/2007 12:32 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
> <de...@openjpa.apache.org>
> Subject
> Persistence of Service Data Objects using OpenJPA
>
>
>
>
>
>
> Hi Frank,
>
> Thank you for your interest. Before I answer the specific questions
> let me say few words to explain why Fluid is attempted at first place.
>
> A) there is a natural synergy between SDO model and the POJO model
> where JPA excels.
> B) Object Persistence (be it strongly-typed POJO or loosely-typed
> SDO) is complex problem by itself. Throw in quirk of multiple database
> vendors -- and one really got a hard problem in hand. OpenJPA,
> Hibernate, TopLink had worked over many years to solve this problem to
> a reasonable degree. SDO persistence should leverage that
> knowledge/effort instead of reinventing a costly wheel.
>
>
> 1) Yes -- you're right. The views expressed in
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29 is in agreement with what promoted me to start the lab
> (actually I checked this page while researching and mentioned in in my
> blog). According to this wiki page: "Work on the specification of a
> JPA data access service by the OSOA collaboration is envisaged
> sometime in the future but has not started yet."
> So Fluid can be considered as a prototype/exploration of similar
> ideas.
>
> 2) Yes, I am aware of SDO's generation of Java and I have played with
> org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided
> to write yet another code generator for Fluid because
>
> a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> Type information defined by XSDHelper.define().
> The annotations in the class will be made optional as we proceed --
> because JPA allows a separate mapping file Orm.xml thereby retaining
> POJO-ness of the persistent domain classes.
>
> b) The generated Java classes is "domain-ready" i.e. they are
> self-consistent and independent. Proof: they can be compiled without
> any other package other that java.util.*. Adding annotation, however,
> makes them compile-dependent on jpa.jar, but that dependency will be
> made optional as mapping information can be externalized in orm.xml.
>
> C) as far as SDO metamodel to Java metamodel mapping goes, it is
> essentially isomorphic (at least for this prototype).
> SDO2POJO does not introduce any extra artifact (see below). I have not
> played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> to make a fair judgement -- but most probably it is generating Java
> classes which has more dependency on framework classes in terms of
> (inheriting/implementing) as well as package imports.
>
> d) One mapping element is introduced in SDO-Java conversion
process.
> It is about "Container" SDO Types. I describe the details in Fluid
> website. The reason for defining a Container Type abstraction is
> better alignment for mapping to relational database (save extra joins
> and allow navigational query across multi-cardinality relation paths).
>
>
> 3) Besides the source code generation route, another possibilities
> is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> that approach too.
>
> Regards --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Friday, July 27, 2007 10:39 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> Hi Pinaki,
>
> This looks very cool, especially that you've got a working prototype!
> I have a couple of questions.
>
> 1) This seems to overlap with the DAS plan described here:
>
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29
>
> I'm not very familiar with the DAS work myself, but there seems to be
> some overlap with your work.
>
> 2) I'm also wondering if you were aware that SDO also defines a
> mapping to static Java interfaces/classes. See section 5 of the SDO
spec:
>
>
> http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL
> .p
> df?version=1
>
> Does your SDO2POJOGenerator conform to that mapping? Have you tried
> the Tuscany static SDO generator
> (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> relashionship?
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
>
> > Hello,
> > I have been asking newbie questions to this forum. And people have
> > been very helpful.
> >
> > Those newbie questions were for a Apache Lab project named Fluid
> > -- to explore possibilities of SDO persistence using JPA API.
> >
> > With all your help, I could put together an initial proptotype
> > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > OpenJPA for SDO and JPA implementation respectively.
> >
> > Further details of this project (with user documentation) can be
> > found at
> >
> > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> >
> > Your comments/suggestions are most welcome --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 4:59 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > EAttribute.isID() will only be true if the type is xsd:ID.
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> >
> > > Hi Frank,
> > > > Database IDs (e.g., primary and foreign keys) are more
> > > related to
> >
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Thanks for telling me this.
> > >
> > > Now is ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID())) == true for a property p that is
> > > declared as xsd:key or xsd:keyref?
> > >
> > > Or broadly, what is the semantics of Eattribute.isID()?
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > Identity support is also in the SDO 3 charter: Support for a
> > > concept
>
> > > of identity in SDO, and its relationship to other technologies.
> > >
> > > Database IDs (e.g., primary and foreign keys) are more related to
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > >
> > > > Hi Frank,
> > > > Thanks.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > >
> > > > That is good news. However, identity mechanics should appear
> > > > more distinctly on API surface e.g.
> > > > boolean Proprty.isIdentifier();
> > > > List<Property> Type.getIdentifiers();
> > > >
> > > > I will qualify absence of any identity semantics from SDO a
> > > > major drawback. Especially, if it comes to any persistence
> > > > operation on SDO DataObject/DataGraph. Hopefully some of the SDO
> > > > spec writers would notice this omission and add it to future
spec version.
> > > >
> > > > After a quick pick in current DAS implementation, it appeared
> > > > that
>
> > > > 'primary key' identification is based on existing database
> > > > column name
> > >
> > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > learn how DAS is handling identity issue.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > > That is a good decision. Wrapping should always provide access
> > > > to what
> > >
> > > > is being wrapped.
> > > >
> > > > > downcasting to the EMF implementation class
> > > >
> > > > Thanks for this info. I will do this for now. But I heed your
> > > > advice
> >
> > > > and have already a scheme in place that programs against *only*
> > > > commonj.sdo API but can access underlying implementaion, if
> > > > available,
> > >
> > > > without any compile-time binding.
> > > > Slightly costly -- but works for, say, extracting package name
> > > > from Types.
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > They can't be distinguished in the current version of SDO
> > > > metadata, you need to look at the original XSD. The next version
> > > > of SDO (SDO
> > > > 3) is planning to provide an api for accessing extended XSD
> > > > metadata. In Tuscany, you can currently determine this by
> > > > downcasting to the EMF implementation class, although we don't
> > recommend people do that:
> > > >
> > > > System.out.println(" Property isID: " +
> > > > ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID()));
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
AM:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > A newbie question:
> > > > > How does two Property: one defined as xsd:string and other
> > > > > as
>
> > > > > xsd:ID can be distiguished?
> > > > >
> > > > > Assume:
> > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > with two properties as follows:
> > > > > <xsd:complexType name="Person">
> > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > 2. TypeHelper.INSTANCE.define()
> > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > firstName)
> > > >
> > > > > and p2 (for id)
> > > > >
> > > > > 3. both p1.getType().getInstanceClass() and
> > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > both p1.getType().isDataType() and
> > > > > p2.getType().isDataType()
>
> > > > > return true
> > > > >
> > > > > The question is, what can be done to identify p2 as a property
> > > > > that were defined as xsd:ID?
> > > > >
> > > > >
> > > > > Thanks for your help --
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > 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.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Luciano,
OpenJPA has organized a face-to-face meeting to discuss current
architecture and future direction. Patrick Linskey, the leader of
OpenJPA, had allowed a 30-minute presentation on Fluid for tomoorow. I
will presnt Fluid to get feedback from the community, their expert views
on how to proceed on this as well as your expressed view on integration
between Tuscany and OpenJPA communities on this regard.
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Monday, August 06, 2007 11:20 AM
To: tuscany-dev@ws.apache.org
Cc: dev@openjpa.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA now
supports Tuscany SDO DAS API
Hey Pinaki
Very good to hear that you also added initial support for the Tuscany
DAS interfaces. BTW, let me ask you what are your plans to Fluid ? My
personal opinion is that this might be a great addition to Tuscany, and
we could have it as another DAS option in Tuscany. This could also
promote a better integration between Tuscany and OpenJPA communities.
Thoughts ?
On 7/31/07, Pinaki Poddar <pp...@bea.com> wrote:
> Hi Luciano,
> In an earlier response to your question:
> > if would be feasible to add a DAS interface[1] layer on top of
> Fluid [2]?
> My answer was: Yes.
>
> As backup of that answer, I just added the support for SDO DAS by
> implementing DASFactory/DAS/Command Using Fluid. These implementations
> are very thin-wrapper that delegates to Fluid's JPA API.
>
> From a usage model, there is conceptual shift though from a
> SQL-based DAS.
>
> Using Fluid based DAS, user code will look like: (there are some
> TestCases that details it)
> DataObject person = createPerson(ssn, "Fluid", "Guy",
> 17);
> DAS das = getDAS();
> Command insert = das.getCommand("INSERT");
> insert.setParameter(0, person);
> insert.execute();
>
> to persist a Person DataObject, or to query
> DAS das = getDAS();
> Command query = das.getCommand("SELECT");
> String jpql = "SELECT o FROM Person o WHERE
> o.firstName=?1 AND o.age=?2";
> query.setParameter(0, jpql);
> query.setParameter(1, "Fluid");
> query.setParameter(2, 17);
> DataObject list = query.executeQuery();
> List result = (List)list.get(0);
>
> Few notable points are:
> 1. There is no SQL.
> 2. All object level paramaters are set via Command.setParameter()
> method.
> Insert command acts on a Person DataObject (insert can be
> cascaded transitively, btw)
> which is passed to it as parameter.
> 3. Query is JPQL. This is a powerful contribution of JPA. The
> namespace of the query
> tokens are Object Domain tokens i.e. SDO Type and Property names;
> not database
> Table or Column names. Join is navigation across a SDO DataGraph.
> OpenJPA will take care of creating the appropriate SQL.
> User can see/monitor what SQL is being generated by OpenJPA.
> 4. DAS defined return of Command.executeQuery() as a DataObject. One
> would prefer it
> to be a List<DataObject> but to confirm to the API, I just return
> a dynamic DataObject
> whose 0-th Property is a List<DataObject>
>
> And, last but not the least, applyChanges():
> dataObject.setString("firstName", "Solid");
> das.applyChanges(dataObject); Will make an UPDATE to
> the database.
>
> How does user application gets a DAS?
>
> DASFactory dasFactory = new FluidDASFactory("SDO-DAS");
> DAS dasFactory = dasfactory.createDAS();
>
> 1. Everything about persistence service (from database connections to
> ~200 configurable parameters
> supported by OpenJPA) is configured in a single file:
> META-INF/persistence.xml.
> The unit name in this file should be <persistence-unit
> unitName="SDO-DAS">.
> 2. The overloaded DASFactory.createDAS() that takes
> org.apache.tuscany.sdo.das.rdb.Config and other
> parameters are supported simply by ignoring the argument :).
>
>
> Regards
>
>
>
>
>
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Luciano Resende [mailto:luckbr1975@gmail.com]
> Sent: Friday, July 27, 2007 3:25 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Persistence of Service Data Objects using OpenJPA
>
> I haven't looked into this with any great detail, but I'd like to ask
> if would be feasible to add a DAS interface[1] layer on top of Fluid
[2].
>
> Thoughts ?
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/ma
> in /java/org/apache/tuscany/das/rdb/DAS.java
> [2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> > Hi Pinaki,
> >
> > I think your project has a lot of potential. Another related aspect
> > is
>
> > that there is interest in the SDO specification charter to discuss
> > the
>
> > possibility of converging/supporting JAXB with static SDO in version
> 3.
> > JAXB2, as you may know, has a similar objective to support standard
> POJOs.
> > If that happens, then I see even more synergy with your approach. At
> > Tuscany, we'd also be very interested in the bytecode generation
> > that you mentioned you've prototyped in Fluid. Tuscany has done a
> > little bit of sandbox prototyping in that area as well, but nobody
> > has had enough time to really pursue it.
> >
> > Given this work, I think you should consider getting involved with
> > the
>
> > DAS specification effort, if you haven't already.
> >
> > Frank.
> >
> >
> >
> >
> > "Pinaki Poddar" <pp...@bea.com>
> > 07/27/2007 12:32 PM
> > Please respond to
> > tuscany-dev@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> > <de...@openjpa.apache.org>
> > Subject
> > Persistence of Service Data Objects using OpenJPA
> >
> >
> >
> >
> >
> >
> > Hi Frank,
> >
> > Thank you for your interest. Before I answer the specific
> > questions
>
> > let me say few words to explain why Fluid is attempted at first
place.
> >
> > A) there is a natural synergy between SDO model and the POJO
> > model where JPA excels.
> > B) Object Persistence (be it strongly-typed POJO or loosely-typed
> > SDO) is complex problem by itself. Throw in quirk of multiple
> > database
>
> > vendors -- and one really got a hard problem in hand. OpenJPA,
> > Hibernate, TopLink had worked over many years to solve this problem
> > to
>
> > a reasonable degree. SDO persistence should leverage that
> > knowledge/effort instead of reinventing a costly wheel.
> >
> >
> > 1) Yes -- you're right. The views expressed in
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architectu
> > re
> > +%
> > 28JPA%29 is in agreement with what promoted me to start the lab
> > (actually I checked this page while researching and mentioned in in
> > my
>
> > blog). According to this wiki page: "Work on the specification of a
> > JPA data access service by the OSOA collaboration is envisaged
> > sometime in the future but has not started yet."
> > So Fluid can be considered as a prototype/exploration of similar
> > ideas.
> >
> > 2) Yes, I am aware of SDO's generation of Java and I have played
> > with
>
> > org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I
> > decided to write yet another code generator for Fluid because
> >
> > a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> > Type information defined by XSDHelper.define().
> > The annotations in the class will be made optional as we proceed --
> > because JPA allows a separate mapping file Orm.xml thereby retaining
> > POJO-ness of the persistent domain classes.
> >
> > b) The generated Java classes is "domain-ready" i.e. they are
> > self-consistent and independent. Proof: they can be compiled without
> > any other package other that java.util.*. Adding annotation,
> > however, makes them compile-dependent on jpa.jar, but that
> > dependency will be made optional as mapping information can be
externalized in orm.xml.
> >
> > C) as far as SDO metamodel to Java metamodel mapping goes, it is
> > essentially isomorphic (at least for this prototype).
> > SDO2POJO does not introduce any extra artifact (see below). I have
> > not
>
> > played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> > to make a fair judgement -- but most probably it is generating Java
> > classes which has more dependency on framework classes in terms of
> > (inheriting/implementing) as well as package imports.
> >
> > d) One mapping element is introduced in SDO-Java conversion
> process.
> > It is about "Container" SDO Types. I describe the details in Fluid
> > website. The reason for defining a Container Type abstraction is
> > better alignment for mapping to relational database (save extra
> > joins and allow navigational query across multi-cardinality relation
paths).
> >
> >
> > 3) Besides the source code generation route, another possibilities
> > is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> > that approach too.
> >
> > Regards --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Friday, July 27, 2007 10:39 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > This looks very cool, especially that you've got a working
prototype!
> > I have a couple of questions.
> >
> > 1) This seems to overlap with the DAS plan described here:
> >
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architectu
> > re
> > +%
> > 28JPA%29
> >
> > I'm not very familiar with the DAS work myself, but there seems to
> > be some overlap with your work.
> >
> > 2) I'm also wondering if you were aware that SDO also defines a
> > mapping to static Java interfaces/classes. See section 5 of the SDO
> spec:
> >
> >
> > http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FIN
> > AL
> > .p
> > df?version=1
> >
> > Does your SDO2POJOGenerator conform to that mapping? Have you tried
> > the Tuscany static SDO generator
> > (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> > relashionship?
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> >
> > > Hello,
> > > I have been asking newbie questions to this forum. And people
> > > have
>
> > > been very helpful.
> > >
> > > Those newbie questions were for a Apache Lab project named Fluid
> > > -- to explore possibilities of SDO persistence using JPA API.
> > >
> > > With all your help, I could put together an initial proptotype
> > > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > > OpenJPA for SDO and JPA implementation respectively.
> > >
> > > Further details of this project (with user documentation) can
> > > be found at
> > >
> > > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> > >
> > > Your comments/suggestions are most welcome --
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 4:59 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > EAttribute.isID() will only be true if the type is xsd:ID.
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> > >
> > > > Hi Frank,
> > > > > Database IDs (e.g., primary and foreign keys) are more
> > > > related to
> > >
> > > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is
> > > > planning
>
> > > > to address all of them :-)
> > > >
> > > > Thanks for telling me this.
> > > >
> > > > Now is ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID())) == true for a property p that is
> > > > declared as xsd:key or xsd:keyref?
> > > >
> > > > Or broadly, what is the semantics of Eattribute.isID()?
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: RE: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > Identity support is also in the SDO 3 charter: Support for a
> > > > concept
> >
> > > > of identity in SDO, and its relationship to other technologies.
> > > >
> > > > Database IDs (e.g., primary and foreign keys) are more related
> > > > to xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is
> > > > planning
>
> > > > to address all of them :-)
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21
AM:
> > > >
> > > > > Hi Frank,
> > > > > Thanks.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > >
> > > > > That is good news. However, identity mechanics should appear
> > > > > more distinctly on API surface e.g.
> > > > > boolean Proprty.isIdentifier();
> > > > > List<Property> Type.getIdentifiers();
> > > > >
> > > > > I will qualify absence of any identity semantics from SDO a
> > > > > major drawback. Especially, if it comes to any persistence
> > > > > operation on SDO DataObject/DataGraph. Hopefully some of the
> > > > > SDO
>
> > > > > spec writers would notice this omission and add it to future
> spec version.
> > > > >
> > > > > After a quick pick in current DAS implementation, it appeared
> > > > > that
> >
> > > > > 'primary key' identification is based on existing database
> > > > > column name
> > > >
> > > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > > learn how DAS is handling identity issue.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > > That is a good decision. Wrapping should always provide access
> > > > > to what
> > > >
> > > > > is being wrapped.
> > > > >
> > > > > > downcasting to the EMF implementation class
> > > > >
> > > > > Thanks for this info. I will do this for now. But I heed your
> > > > > advice
> > >
> > > > > and have already a scheme in place that programs against
> > > > > *only* commonj.sdo API but can access underlying
> > > > > implementaion, if available,
> > > >
> > > > > without any compile-time binding.
> > > > > Slightly costly -- but works for, say, extracting package name
> > > > > from Types.
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > > To: tuscany-dev@ws.apache.org
> > > > > Subject: Re: How does xsd:ID property type is distinguished
> > > > > from
>
> > > > > xsd:string
> > > > >
> > > > > Hi Pinaki,
> > > > >
> > > > > They can't be distinguished in the current version of SDO
> > > > > metadata, you need to look at the original XSD. The next
> > > > > version
>
> > > > > of SDO (SDO
> > > > > 3) is planning to provide an api for accessing extended XSD
> > > > > metadata. In Tuscany, you can currently determine this by
> > > > > downcasting to the EMF implementation class, although we don't
> > > recommend people do that:
> > > > >
> > > > > System.out.println(" Property isID: " +
> > > > > ((property.getType().isDataType()) &&
> > > > > ((EAttribute)property).isID()));
> > > > >
> > > > > Frank.
> > > > >
> > > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
> AM:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > A newbie question:
> > > > > > How does two Property: one defined as xsd:string and
> > > > > > other as
> >
> > > > > > xsd:ID can be distiguished?
> > > > > >
> > > > > > Assume:
> > > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > > with two properties as follows:
> > > > > > <xsd:complexType name="Person">
> > > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > 2. TypeHelper.INSTANCE.define()
> > > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > > firstName)
> > > > >
> > > > > > and p2 (for id)
> > > > > >
> > > > > > 3. both p1.getType().getInstanceClass() and
> > > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > > both p1.getType().isDataType() and
> > > > > > p2.getType().isDataType()
> >
> > > > > > return true
> > > > > >
> > > > > > The question is, what can be done to identify p2 as a
> > > > > > property
>
> > > > > > that were defined as xsd:ID?
> > > > > >
> > > > > >
> > > > > > Thanks for your help --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pinaki Poddar
> > > > > > 972.834.2865
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > ------------------------------------------------------------
> > > > > > --
> > > > > > --
> > > > > > --
> > > > > > --
> > > > > > - To unsubscribe, e-mail:
> > > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > tuscany-dev-help@ws.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Luciano,
OpenJPA has organized a face-to-face meeting to discuss current
architecture and future direction. Patrick Linskey, the leader of
OpenJPA, had allowed a 30-minute presentation on Fluid for tomoorow. I
will presnt Fluid to get feedback from the community, their expert views
on how to proceed on this as well as your expressed view on integration
between Tuscany and OpenJPA communities on this regard.
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Monday, August 06, 2007 11:20 AM
To: tuscany-dev@ws.apache.org
Cc: dev@openjpa.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA now
supports Tuscany SDO DAS API
Hey Pinaki
Very good to hear that you also added initial support for the Tuscany
DAS interfaces. BTW, let me ask you what are your plans to Fluid ? My
personal opinion is that this might be a great addition to Tuscany, and
we could have it as another DAS option in Tuscany. This could also
promote a better integration between Tuscany and OpenJPA communities.
Thoughts ?
On 7/31/07, Pinaki Poddar <pp...@bea.com> wrote:
> Hi Luciano,
> In an earlier response to your question:
> > if would be feasible to add a DAS interface[1] layer on top of
> Fluid [2]?
> My answer was: Yes.
>
> As backup of that answer, I just added the support for SDO DAS by
> implementing DASFactory/DAS/Command Using Fluid. These implementations
> are very thin-wrapper that delegates to Fluid's JPA API.
>
> From a usage model, there is conceptual shift though from a
> SQL-based DAS.
>
> Using Fluid based DAS, user code will look like: (there are some
> TestCases that details it)
> DataObject person = createPerson(ssn, "Fluid", "Guy",
> 17);
> DAS das = getDAS();
> Command insert = das.getCommand("INSERT");
> insert.setParameter(0, person);
> insert.execute();
>
> to persist a Person DataObject, or to query
> DAS das = getDAS();
> Command query = das.getCommand("SELECT");
> String jpql = "SELECT o FROM Person o WHERE
> o.firstName=?1 AND o.age=?2";
> query.setParameter(0, jpql);
> query.setParameter(1, "Fluid");
> query.setParameter(2, 17);
> DataObject list = query.executeQuery();
> List result = (List)list.get(0);
>
> Few notable points are:
> 1. There is no SQL.
> 2. All object level paramaters are set via Command.setParameter()
> method.
> Insert command acts on a Person DataObject (insert can be
> cascaded transitively, btw)
> which is passed to it as parameter.
> 3. Query is JPQL. This is a powerful contribution of JPA. The
> namespace of the query
> tokens are Object Domain tokens i.e. SDO Type and Property names;
> not database
> Table or Column names. Join is navigation across a SDO DataGraph.
> OpenJPA will take care of creating the appropriate SQL.
> User can see/monitor what SQL is being generated by OpenJPA.
> 4. DAS defined return of Command.executeQuery() as a DataObject. One
> would prefer it
> to be a List<DataObject> but to confirm to the API, I just return
> a dynamic DataObject
> whose 0-th Property is a List<DataObject>
>
> And, last but not the least, applyChanges():
> dataObject.setString("firstName", "Solid");
> das.applyChanges(dataObject); Will make an UPDATE to
> the database.
>
> How does user application gets a DAS?
>
> DASFactory dasFactory = new FluidDASFactory("SDO-DAS");
> DAS dasFactory = dasfactory.createDAS();
>
> 1. Everything about persistence service (from database connections to
> ~200 configurable parameters
> supported by OpenJPA) is configured in a single file:
> META-INF/persistence.xml.
> The unit name in this file should be <persistence-unit
> unitName="SDO-DAS">.
> 2. The overloaded DASFactory.createDAS() that takes
> org.apache.tuscany.sdo.das.rdb.Config and other
> parameters are supported simply by ignoring the argument :).
>
>
> Regards
>
>
>
>
>
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Luciano Resende [mailto:luckbr1975@gmail.com]
> Sent: Friday, July 27, 2007 3:25 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Persistence of Service Data Objects using OpenJPA
>
> I haven't looked into this with any great detail, but I'd like to ask
> if would be feasible to add a DAS interface[1] layer on top of Fluid
[2].
>
> Thoughts ?
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/ma
> in /java/org/apache/tuscany/das/rdb/DAS.java
> [2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> > Hi Pinaki,
> >
> > I think your project has a lot of potential. Another related aspect
> > is
>
> > that there is interest in the SDO specification charter to discuss
> > the
>
> > possibility of converging/supporting JAXB with static SDO in version
> 3.
> > JAXB2, as you may know, has a similar objective to support standard
> POJOs.
> > If that happens, then I see even more synergy with your approach. At
> > Tuscany, we'd also be very interested in the bytecode generation
> > that you mentioned you've prototyped in Fluid. Tuscany has done a
> > little bit of sandbox prototyping in that area as well, but nobody
> > has had enough time to really pursue it.
> >
> > Given this work, I think you should consider getting involved with
> > the
>
> > DAS specification effort, if you haven't already.
> >
> > Frank.
> >
> >
> >
> >
> > "Pinaki Poddar" <pp...@bea.com>
> > 07/27/2007 12:32 PM
> > Please respond to
> > tuscany-dev@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> > <de...@openjpa.apache.org>
> > Subject
> > Persistence of Service Data Objects using OpenJPA
> >
> >
> >
> >
> >
> >
> > Hi Frank,
> >
> > Thank you for your interest. Before I answer the specific
> > questions
>
> > let me say few words to explain why Fluid is attempted at first
place.
> >
> > A) there is a natural synergy between SDO model and the POJO
> > model where JPA excels.
> > B) Object Persistence (be it strongly-typed POJO or loosely-typed
> > SDO) is complex problem by itself. Throw in quirk of multiple
> > database
>
> > vendors -- and one really got a hard problem in hand. OpenJPA,
> > Hibernate, TopLink had worked over many years to solve this problem
> > to
>
> > a reasonable degree. SDO persistence should leverage that
> > knowledge/effort instead of reinventing a costly wheel.
> >
> >
> > 1) Yes -- you're right. The views expressed in
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architectu
> > re
> > +%
> > 28JPA%29 is in agreement with what promoted me to start the lab
> > (actually I checked this page while researching and mentioned in in
> > my
>
> > blog). According to this wiki page: "Work on the specification of a
> > JPA data access service by the OSOA collaboration is envisaged
> > sometime in the future but has not started yet."
> > So Fluid can be considered as a prototype/exploration of similar
> > ideas.
> >
> > 2) Yes, I am aware of SDO's generation of Java and I have played
> > with
>
> > org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I
> > decided to write yet another code generator for Fluid because
> >
> > a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> > Type information defined by XSDHelper.define().
> > The annotations in the class will be made optional as we proceed --
> > because JPA allows a separate mapping file Orm.xml thereby retaining
> > POJO-ness of the persistent domain classes.
> >
> > b) The generated Java classes is "domain-ready" i.e. they are
> > self-consistent and independent. Proof: they can be compiled without
> > any other package other that java.util.*. Adding annotation,
> > however, makes them compile-dependent on jpa.jar, but that
> > dependency will be made optional as mapping information can be
externalized in orm.xml.
> >
> > C) as far as SDO metamodel to Java metamodel mapping goes, it is
> > essentially isomorphic (at least for this prototype).
> > SDO2POJO does not introduce any extra artifact (see below). I have
> > not
>
> > played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> > to make a fair judgement -- but most probably it is generating Java
> > classes which has more dependency on framework classes in terms of
> > (inheriting/implementing) as well as package imports.
> >
> > d) One mapping element is introduced in SDO-Java conversion
> process.
> > It is about "Container" SDO Types. I describe the details in Fluid
> > website. The reason for defining a Container Type abstraction is
> > better alignment for mapping to relational database (save extra
> > joins and allow navigational query across multi-cardinality relation
paths).
> >
> >
> > 3) Besides the source code generation route, another possibilities
> > is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> > that approach too.
> >
> > Regards --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Friday, July 27, 2007 10:39 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > This looks very cool, especially that you've got a working
prototype!
> > I have a couple of questions.
> >
> > 1) This seems to overlap with the DAS plan described here:
> >
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architectu
> > re
> > +%
> > 28JPA%29
> >
> > I'm not very familiar with the DAS work myself, but there seems to
> > be some overlap with your work.
> >
> > 2) I'm also wondering if you were aware that SDO also defines a
> > mapping to static Java interfaces/classes. See section 5 of the SDO
> spec:
> >
> >
> > http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FIN
> > AL
> > .p
> > df?version=1
> >
> > Does your SDO2POJOGenerator conform to that mapping? Have you tried
> > the Tuscany static SDO generator
> > (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> > relashionship?
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> >
> > > Hello,
> > > I have been asking newbie questions to this forum. And people
> > > have
>
> > > been very helpful.
> > >
> > > Those newbie questions were for a Apache Lab project named Fluid
> > > -- to explore possibilities of SDO persistence using JPA API.
> > >
> > > With all your help, I could put together an initial proptotype
> > > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > > OpenJPA for SDO and JPA implementation respectively.
> > >
> > > Further details of this project (with user documentation) can
> > > be found at
> > >
> > > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> > >
> > > Your comments/suggestions are most welcome --
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 4:59 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > EAttribute.isID() will only be true if the type is xsd:ID.
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> > >
> > > > Hi Frank,
> > > > > Database IDs (e.g., primary and foreign keys) are more
> > > > related to
> > >
> > > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is
> > > > planning
>
> > > > to address all of them :-)
> > > >
> > > > Thanks for telling me this.
> > > >
> > > > Now is ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID())) == true for a property p that is
> > > > declared as xsd:key or xsd:keyref?
> > > >
> > > > Or broadly, what is the semantics of Eattribute.isID()?
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: RE: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > Identity support is also in the SDO 3 charter: Support for a
> > > > concept
> >
> > > > of identity in SDO, and its relationship to other technologies.
> > > >
> > > > Database IDs (e.g., primary and foreign keys) are more related
> > > > to xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is
> > > > planning
>
> > > > to address all of them :-)
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21
AM:
> > > >
> > > > > Hi Frank,
> > > > > Thanks.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > >
> > > > > That is good news. However, identity mechanics should appear
> > > > > more distinctly on API surface e.g.
> > > > > boolean Proprty.isIdentifier();
> > > > > List<Property> Type.getIdentifiers();
> > > > >
> > > > > I will qualify absence of any identity semantics from SDO a
> > > > > major drawback. Especially, if it comes to any persistence
> > > > > operation on SDO DataObject/DataGraph. Hopefully some of the
> > > > > SDO
>
> > > > > spec writers would notice this omission and add it to future
> spec version.
> > > > >
> > > > > After a quick pick in current DAS implementation, it appeared
> > > > > that
> >
> > > > > 'primary key' identification is based on existing database
> > > > > column name
> > > >
> > > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > > learn how DAS is handling identity issue.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > > That is a good decision. Wrapping should always provide access
> > > > > to what
> > > >
> > > > > is being wrapped.
> > > > >
> > > > > > downcasting to the EMF implementation class
> > > > >
> > > > > Thanks for this info. I will do this for now. But I heed your
> > > > > advice
> > >
> > > > > and have already a scheme in place that programs against
> > > > > *only* commonj.sdo API but can access underlying
> > > > > implementaion, if available,
> > > >
> > > > > without any compile-time binding.
> > > > > Slightly costly -- but works for, say, extracting package name
> > > > > from Types.
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > > To: tuscany-dev@ws.apache.org
> > > > > Subject: Re: How does xsd:ID property type is distinguished
> > > > > from
>
> > > > > xsd:string
> > > > >
> > > > > Hi Pinaki,
> > > > >
> > > > > They can't be distinguished in the current version of SDO
> > > > > metadata, you need to look at the original XSD. The next
> > > > > version
>
> > > > > of SDO (SDO
> > > > > 3) is planning to provide an api for accessing extended XSD
> > > > > metadata. In Tuscany, you can currently determine this by
> > > > > downcasting to the EMF implementation class, although we don't
> > > recommend people do that:
> > > > >
> > > > > System.out.println(" Property isID: " +
> > > > > ((property.getType().isDataType()) &&
> > > > > ((EAttribute)property).isID()));
> > > > >
> > > > > Frank.
> > > > >
> > > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
> AM:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > A newbie question:
> > > > > > How does two Property: one defined as xsd:string and
> > > > > > other as
> >
> > > > > > xsd:ID can be distiguished?
> > > > > >
> > > > > > Assume:
> > > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > > with two properties as follows:
> > > > > > <xsd:complexType name="Person">
> > > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > 2. TypeHelper.INSTANCE.define()
> > > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > > firstName)
> > > > >
> > > > > > and p2 (for id)
> > > > > >
> > > > > > 3. both p1.getType().getInstanceClass() and
> > > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > > both p1.getType().isDataType() and
> > > > > > p2.getType().isDataType()
> >
> > > > > > return true
> > > > > >
> > > > > > The question is, what can be done to identify p2 as a
> > > > > > property
>
> > > > > > that were defined as xsd:ID?
> > > > > >
> > > > > >
> > > > > > Thanks for your help --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pinaki Poddar
> > > > > > 972.834.2865
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > ------------------------------------------------------------
> > > > > > --
> > > > > > --
> > > > > > --
> > > > > > --
> > > > > > - To unsubscribe, e-mail:
> > > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > tuscany-dev-help@ws.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
Re: Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Posted by Luciano Resende <lu...@gmail.com>.
Hey Pinaki
Very good to hear that you also added initial support for the
Tuscany DAS interfaces. BTW, let me ask you what are your plans to
Fluid ? My personal opinion is that this might be a great addition to
Tuscany, and we could have it as another DAS option in Tuscany. This
could also promote a better integration between Tuscany and OpenJPA
communities.
Thoughts ?
On 7/31/07, Pinaki Poddar <pp...@bea.com> wrote:
> Hi Luciano,
> In an earlier response to your question:
> > if would be feasible to add a DAS interface[1] layer on top of Fluid
> [2]?
> My answer was: Yes.
>
> As backup of that answer, I just added the support for SDO DAS by
> implementing DASFactory/DAS/Command
> Using Fluid. These implementations are very thin-wrapper that delegates
> to Fluid's JPA API.
>
> From a usage model, there is conceptual shift though from a SQL-based
> DAS.
>
> Using Fluid based DAS, user code will look like: (there are some
> TestCases that details it)
> DataObject person = createPerson(ssn, "Fluid", "Guy",
> 17);
> DAS das = getDAS();
> Command insert = das.getCommand("INSERT");
> insert.setParameter(0, person);
> insert.execute();
>
> to persist a Person DataObject, or to query
> DAS das = getDAS();
> Command query = das.getCommand("SELECT");
> String jpql = "SELECT o FROM Person o WHERE
> o.firstName=?1 AND o.age=?2";
> query.setParameter(0, jpql);
> query.setParameter(1, "Fluid");
> query.setParameter(2, 17);
> DataObject list = query.executeQuery();
> List result = (List)list.get(0);
>
> Few notable points are:
> 1. There is no SQL.
> 2. All object level paramaters are set via Command.setParameter()
> method.
> Insert command acts on a Person DataObject (insert can be cascaded
> transitively, btw)
> which is passed to it as parameter.
> 3. Query is JPQL. This is a powerful contribution of JPA. The
> namespace of the query
> tokens are Object Domain tokens i.e. SDO Type and Property names;
> not database
> Table or Column names. Join is navigation across a SDO DataGraph.
> OpenJPA will take care of creating the appropriate SQL.
> User can see/monitor what SQL is being generated by OpenJPA.
> 4. DAS defined return of Command.executeQuery() as a DataObject. One
> would prefer it
> to be a List<DataObject> but to confirm to the API, I just return a
> dynamic DataObject
> whose 0-th Property is a List<DataObject>
>
> And, last but not the least, applyChanges():
> dataObject.setString("firstName", "Solid");
> das.applyChanges(dataObject);
> Will make an UPDATE to the database.
>
> How does user application gets a DAS?
>
> DASFactory dasFactory = new FluidDASFactory("SDO-DAS");
> DAS dasFactory = dasfactory.createDAS();
>
> 1. Everything about persistence service (from database connections to
> ~200 configurable parameters
> supported by OpenJPA) is configured in a single file:
> META-INF/persistence.xml.
> The unit name in this file should be <persistence-unit
> unitName="SDO-DAS">.
> 2. The overloaded DASFactory.createDAS() that takes
> org.apache.tuscany.sdo.das.rdb.Config and other
> parameters are supported simply by ignoring the argument :).
>
>
> Regards
>
>
>
>
>
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Luciano Resende [mailto:luckbr1975@gmail.com]
> Sent: Friday, July 27, 2007 3:25 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Persistence of Service Data Objects using OpenJPA
>
> I haven't looked into this with any great detail, but I'd like to ask if
> would be feasible to add a DAS interface[1] layer on top of Fluid [2].
>
> Thoughts ?
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main
> /java/org/apache/tuscany/das/rdb/DAS.java
> [2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> > Hi Pinaki,
> >
> > I think your project has a lot of potential. Another related aspect is
>
> > that there is interest in the SDO specification charter to discuss the
>
> > possibility of converging/supporting JAXB with static SDO in version
> 3.
> > JAXB2, as you may know, has a similar objective to support standard
> POJOs.
> > If that happens, then I see even more synergy with your approach. At
> > Tuscany, we'd also be very interested in the bytecode generation that
> > you mentioned you've prototyped in Fluid. Tuscany has done a little
> > bit of sandbox prototyping in that area as well, but nobody has had
> > enough time to really pursue it.
> >
> > Given this work, I think you should consider getting involved with the
>
> > DAS specification effort, if you haven't already.
> >
> > Frank.
> >
> >
> >
> >
> > "Pinaki Poddar" <pp...@bea.com>
> > 07/27/2007 12:32 PM
> > Please respond to
> > tuscany-dev@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> > <de...@openjpa.apache.org>
> > Subject
> > Persistence of Service Data Objects using OpenJPA
> >
> >
> >
> >
> >
> >
> > Hi Frank,
> >
> > Thank you for your interest. Before I answer the specific questions
>
> > let me say few words to explain why Fluid is attempted at first place.
> >
> > A) there is a natural synergy between SDO model and the POJO model
> > where JPA excels.
> > B) Object Persistence (be it strongly-typed POJO or loosely-typed
> > SDO) is complex problem by itself. Throw in quirk of multiple database
>
> > vendors -- and one really got a hard problem in hand. OpenJPA,
> > Hibernate, TopLink had worked over many years to solve this problem to
>
> > a reasonable degree. SDO persistence should leverage that
> > knowledge/effort instead of reinventing a costly wheel.
> >
> >
> > 1) Yes -- you're right. The views expressed in
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> > +%
> > 28JPA%29 is in agreement with what promoted me to start the lab
> > (actually I checked this page while researching and mentioned in in my
>
> > blog). According to this wiki page: "Work on the specification of a
> > JPA data access service by the OSOA collaboration is envisaged
> > sometime in the future but has not started yet."
> > So Fluid can be considered as a prototype/exploration of similar
> > ideas.
> >
> > 2) Yes, I am aware of SDO's generation of Java and I have played with
>
> > org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided
> > to write yet another code generator for Fluid because
> >
> > a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> > Type information defined by XSDHelper.define().
> > The annotations in the class will be made optional as we proceed --
> > because JPA allows a separate mapping file Orm.xml thereby retaining
> > POJO-ness of the persistent domain classes.
> >
> > b) The generated Java classes is "domain-ready" i.e. they are
> > self-consistent and independent. Proof: they can be compiled without
> > any other package other that java.util.*. Adding annotation, however,
> > makes them compile-dependent on jpa.jar, but that dependency will be
> > made optional as mapping information can be externalized in orm.xml.
> >
> > C) as far as SDO metamodel to Java metamodel mapping goes, it is
> > essentially isomorphic (at least for this prototype).
> > SDO2POJO does not introduce any extra artifact (see below). I have not
>
> > played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> > to make a fair judgement -- but most probably it is generating Java
> > classes which has more dependency on framework classes in terms of
> > (inheriting/implementing) as well as package imports.
> >
> > d) One mapping element is introduced in SDO-Java conversion
> process.
> > It is about "Container" SDO Types. I describe the details in Fluid
> > website. The reason for defining a Container Type abstraction is
> > better alignment for mapping to relational database (save extra joins
> > and allow navigational query across multi-cardinality relation paths).
> >
> >
> > 3) Besides the source code generation route, another possibilities
> > is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> > that approach too.
> >
> > Regards --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Friday, July 27, 2007 10:39 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > This looks very cool, especially that you've got a working prototype!
> > I have a couple of questions.
> >
> > 1) This seems to overlap with the DAS plan described here:
> >
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> > +%
> > 28JPA%29
> >
> > I'm not very familiar with the DAS work myself, but there seems to be
> > some overlap with your work.
> >
> > 2) I'm also wondering if you were aware that SDO also defines a
> > mapping to static Java interfaces/classes. See section 5 of the SDO
> spec:
> >
> >
> > http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL
> > .p
> > df?version=1
> >
> > Does your SDO2POJOGenerator conform to that mapping? Have you tried
> > the Tuscany static SDO generator
> > (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> > relashionship?
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> >
> > > Hello,
> > > I have been asking newbie questions to this forum. And people have
>
> > > been very helpful.
> > >
> > > Those newbie questions were for a Apache Lab project named Fluid
> > > -- to explore possibilities of SDO persistence using JPA API.
> > >
> > > With all your help, I could put together an initial proptotype
> > > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > > OpenJPA for SDO and JPA implementation respectively.
> > >
> > > Further details of this project (with user documentation) can be
> > > found at
> > >
> > > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> > >
> > > Your comments/suggestions are most welcome --
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 4:59 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > EAttribute.isID() will only be true if the type is xsd:ID.
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> > >
> > > > Hi Frank,
> > > > > Database IDs (e.g., primary and foreign keys) are more
> > > > related to
> > >
> > > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
>
> > > > to address all of them :-)
> > > >
> > > > Thanks for telling me this.
> > > >
> > > > Now is ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID())) == true for a property p that is
> > > > declared as xsd:key or xsd:keyref?
> > > >
> > > > Or broadly, what is the semantics of Eattribute.isID()?
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: RE: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > Identity support is also in the SDO 3 charter: Support for a
> > > > concept
> >
> > > > of identity in SDO, and its relationship to other technologies.
> > > >
> > > > Database IDs (e.g., primary and foreign keys) are more related to
> > > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
>
> > > > to address all of them :-)
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > > >
> > > > > Hi Frank,
> > > > > Thanks.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > >
> > > > > That is good news. However, identity mechanics should appear
> > > > > more distinctly on API surface e.g.
> > > > > boolean Proprty.isIdentifier();
> > > > > List<Property> Type.getIdentifiers();
> > > > >
> > > > > I will qualify absence of any identity semantics from SDO a
> > > > > major drawback. Especially, if it comes to any persistence
> > > > > operation on SDO DataObject/DataGraph. Hopefully some of the SDO
>
> > > > > spec writers would notice this omission and add it to future
> spec version.
> > > > >
> > > > > After a quick pick in current DAS implementation, it appeared
> > > > > that
> >
> > > > > 'primary key' identification is based on existing database
> > > > > column name
> > > >
> > > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > > learn how DAS is handling identity issue.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > > That is a good decision. Wrapping should always provide access
> > > > > to what
> > > >
> > > > > is being wrapped.
> > > > >
> > > > > > downcasting to the EMF implementation class
> > > > >
> > > > > Thanks for this info. I will do this for now. But I heed your
> > > > > advice
> > >
> > > > > and have already a scheme in place that programs against *only*
> > > > > commonj.sdo API but can access underlying implementaion, if
> > > > > available,
> > > >
> > > > > without any compile-time binding.
> > > > > Slightly costly -- but works for, say, extracting package name
> > > > > from Types.
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > > To: tuscany-dev@ws.apache.org
> > > > > Subject: Re: How does xsd:ID property type is distinguished from
>
> > > > > xsd:string
> > > > >
> > > > > Hi Pinaki,
> > > > >
> > > > > They can't be distinguished in the current version of SDO
> > > > > metadata, you need to look at the original XSD. The next version
>
> > > > > of SDO (SDO
> > > > > 3) is planning to provide an api for accessing extended XSD
> > > > > metadata. In Tuscany, you can currently determine this by
> > > > > downcasting to the EMF implementation class, although we don't
> > > recommend people do that:
> > > > >
> > > > > System.out.println(" Property isID: " +
> > > > > ((property.getType().isDataType()) &&
> > > > > ((EAttribute)property).isID()));
> > > > >
> > > > > Frank.
> > > > >
> > > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
> AM:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > A newbie question:
> > > > > > How does two Property: one defined as xsd:string and other
> > > > > > as
> >
> > > > > > xsd:ID can be distiguished?
> > > > > >
> > > > > > Assume:
> > > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > > with two properties as follows:
> > > > > > <xsd:complexType name="Person">
> > > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > 2. TypeHelper.INSTANCE.define()
> > > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > > firstName)
> > > > >
> > > > > > and p2 (for id)
> > > > > >
> > > > > > 3. both p1.getType().getInstanceClass() and
> > > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > > both p1.getType().isDataType() and
> > > > > > p2.getType().isDataType()
> >
> > > > > > return true
> > > > > >
> > > > > > The question is, what can be done to identify p2 as a property
>
> > > > > > that were defined as xsd:ID?
> > > > > >
> > > > > >
> > > > > > Thanks for your help --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pinaki Poddar
> > > > > > 972.834.2865
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > --------------------------------------------------------------
> > > > > > --
> > > > > > --
> > > > > > --
> > > > > > - To unsubscribe, e-mail:
> > > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > tuscany-dev-help@ws.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Posted by Luciano Resende <lu...@gmail.com>.
Hey Pinaki
Very good to hear that you also added initial support for the
Tuscany DAS interfaces. BTW, let me ask you what are your plans to
Fluid ? My personal opinion is that this might be a great addition to
Tuscany, and we could have it as another DAS option in Tuscany. This
could also promote a better integration between Tuscany and OpenJPA
communities.
Thoughts ?
On 7/31/07, Pinaki Poddar <pp...@bea.com> wrote:
> Hi Luciano,
> In an earlier response to your question:
> > if would be feasible to add a DAS interface[1] layer on top of Fluid
> [2]?
> My answer was: Yes.
>
> As backup of that answer, I just added the support for SDO DAS by
> implementing DASFactory/DAS/Command
> Using Fluid. These implementations are very thin-wrapper that delegates
> to Fluid's JPA API.
>
> From a usage model, there is conceptual shift though from a SQL-based
> DAS.
>
> Using Fluid based DAS, user code will look like: (there are some
> TestCases that details it)
> DataObject person = createPerson(ssn, "Fluid", "Guy",
> 17);
> DAS das = getDAS();
> Command insert = das.getCommand("INSERT");
> insert.setParameter(0, person);
> insert.execute();
>
> to persist a Person DataObject, or to query
> DAS das = getDAS();
> Command query = das.getCommand("SELECT");
> String jpql = "SELECT o FROM Person o WHERE
> o.firstName=?1 AND o.age=?2";
> query.setParameter(0, jpql);
> query.setParameter(1, "Fluid");
> query.setParameter(2, 17);
> DataObject list = query.executeQuery();
> List result = (List)list.get(0);
>
> Few notable points are:
> 1. There is no SQL.
> 2. All object level paramaters are set via Command.setParameter()
> method.
> Insert command acts on a Person DataObject (insert can be cascaded
> transitively, btw)
> which is passed to it as parameter.
> 3. Query is JPQL. This is a powerful contribution of JPA. The
> namespace of the query
> tokens are Object Domain tokens i.e. SDO Type and Property names;
> not database
> Table or Column names. Join is navigation across a SDO DataGraph.
> OpenJPA will take care of creating the appropriate SQL.
> User can see/monitor what SQL is being generated by OpenJPA.
> 4. DAS defined return of Command.executeQuery() as a DataObject. One
> would prefer it
> to be a List<DataObject> but to confirm to the API, I just return a
> dynamic DataObject
> whose 0-th Property is a List<DataObject>
>
> And, last but not the least, applyChanges():
> dataObject.setString("firstName", "Solid");
> das.applyChanges(dataObject);
> Will make an UPDATE to the database.
>
> How does user application gets a DAS?
>
> DASFactory dasFactory = new FluidDASFactory("SDO-DAS");
> DAS dasFactory = dasfactory.createDAS();
>
> 1. Everything about persistence service (from database connections to
> ~200 configurable parameters
> supported by OpenJPA) is configured in a single file:
> META-INF/persistence.xml.
> The unit name in this file should be <persistence-unit
> unitName="SDO-DAS">.
> 2. The overloaded DASFactory.createDAS() that takes
> org.apache.tuscany.sdo.das.rdb.Config and other
> parameters are supported simply by ignoring the argument :).
>
>
> Regards
>
>
>
>
>
>
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Luciano Resende [mailto:luckbr1975@gmail.com]
> Sent: Friday, July 27, 2007 3:25 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Persistence of Service Data Objects using OpenJPA
>
> I haven't looked into this with any great detail, but I'd like to ask if
> would be feasible to add a DAS interface[1] layer on top of Fluid [2].
>
> Thoughts ?
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main
> /java/org/apache/tuscany/das/rdb/DAS.java
> [2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> > Hi Pinaki,
> >
> > I think your project has a lot of potential. Another related aspect is
>
> > that there is interest in the SDO specification charter to discuss the
>
> > possibility of converging/supporting JAXB with static SDO in version
> 3.
> > JAXB2, as you may know, has a similar objective to support standard
> POJOs.
> > If that happens, then I see even more synergy with your approach. At
> > Tuscany, we'd also be very interested in the bytecode generation that
> > you mentioned you've prototyped in Fluid. Tuscany has done a little
> > bit of sandbox prototyping in that area as well, but nobody has had
> > enough time to really pursue it.
> >
> > Given this work, I think you should consider getting involved with the
>
> > DAS specification effort, if you haven't already.
> >
> > Frank.
> >
> >
> >
> >
> > "Pinaki Poddar" <pp...@bea.com>
> > 07/27/2007 12:32 PM
> > Please respond to
> > tuscany-dev@ws.apache.org
> >
> >
> > To
> > <tu...@ws.apache.org>
> > cc
> > <de...@openjpa.apache.org>
> > Subject
> > Persistence of Service Data Objects using OpenJPA
> >
> >
> >
> >
> >
> >
> > Hi Frank,
> >
> > Thank you for your interest. Before I answer the specific questions
>
> > let me say few words to explain why Fluid is attempted at first place.
> >
> > A) there is a natural synergy between SDO model and the POJO model
> > where JPA excels.
> > B) Object Persistence (be it strongly-typed POJO or loosely-typed
> > SDO) is complex problem by itself. Throw in quirk of multiple database
>
> > vendors -- and one really got a hard problem in hand. OpenJPA,
> > Hibernate, TopLink had worked over many years to solve this problem to
>
> > a reasonable degree. SDO persistence should leverage that
> > knowledge/effort instead of reinventing a costly wheel.
> >
> >
> > 1) Yes -- you're right. The views expressed in
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> > +%
> > 28JPA%29 is in agreement with what promoted me to start the lab
> > (actually I checked this page while researching and mentioned in in my
>
> > blog). According to this wiki page: "Work on the specification of a
> > JPA data access service by the OSOA collaboration is envisaged
> > sometime in the future but has not started yet."
> > So Fluid can be considered as a prototype/exploration of similar
> > ideas.
> >
> > 2) Yes, I am aware of SDO's generation of Java and I have played with
>
> > org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided
> > to write yet another code generator for Fluid because
> >
> > a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> > Type information defined by XSDHelper.define().
> > The annotations in the class will be made optional as we proceed --
> > because JPA allows a separate mapping file Orm.xml thereby retaining
> > POJO-ness of the persistent domain classes.
> >
> > b) The generated Java classes is "domain-ready" i.e. they are
> > self-consistent and independent. Proof: they can be compiled without
> > any other package other that java.util.*. Adding annotation, however,
> > makes them compile-dependent on jpa.jar, but that dependency will be
> > made optional as mapping information can be externalized in orm.xml.
> >
> > C) as far as SDO metamodel to Java metamodel mapping goes, it is
> > essentially isomorphic (at least for this prototype).
> > SDO2POJO does not introduce any extra artifact (see below). I have not
>
> > played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> > to make a fair judgement -- but most probably it is generating Java
> > classes which has more dependency on framework classes in terms of
> > (inheriting/implementing) as well as package imports.
> >
> > d) One mapping element is introduced in SDO-Java conversion
> process.
> > It is about "Container" SDO Types. I describe the details in Fluid
> > website. The reason for defining a Container Type abstraction is
> > better alignment for mapping to relational database (save extra joins
> > and allow navigational query across multi-cardinality relation paths).
> >
> >
> > 3) Besides the source code generation route, another possibilities
> > is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> > that approach too.
> >
> > Regards --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Friday, July 27, 2007 10:39 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > This looks very cool, especially that you've got a working prototype!
> > I have a couple of questions.
> >
> > 1) This seems to overlap with the DAS plan described here:
> >
> >
> > http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> > +%
> > 28JPA%29
> >
> > I'm not very familiar with the DAS work myself, but there seems to be
> > some overlap with your work.
> >
> > 2) I'm also wondering if you were aware that SDO also defines a
> > mapping to static Java interfaces/classes. See section 5 of the SDO
> spec:
> >
> >
> > http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL
> > .p
> > df?version=1
> >
> > Does your SDO2POJOGenerator conform to that mapping? Have you tried
> > the Tuscany static SDO generator
> > (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> > relashionship?
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> >
> > > Hello,
> > > I have been asking newbie questions to this forum. And people have
>
> > > been very helpful.
> > >
> > > Those newbie questions were for a Apache Lab project named Fluid
> > > -- to explore possibilities of SDO persistence using JPA API.
> > >
> > > With all your help, I could put together an initial proptotype
> > > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > > OpenJPA for SDO and JPA implementation respectively.
> > >
> > > Further details of this project (with user documentation) can be
> > > found at
> > >
> > > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> > >
> > > Your comments/suggestions are most welcome --
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 4:59 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > EAttribute.isID() will only be true if the type is xsd:ID.
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> > >
> > > > Hi Frank,
> > > > > Database IDs (e.g., primary and foreign keys) are more
> > > > related to
> > >
> > > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
>
> > > > to address all of them :-)
> > > >
> > > > Thanks for telling me this.
> > > >
> > > > Now is ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID())) == true for a property p that is
> > > > declared as xsd:key or xsd:keyref?
> > > >
> > > > Or broadly, what is the semantics of Eattribute.isID()?
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: RE: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > Identity support is also in the SDO 3 charter: Support for a
> > > > concept
> >
> > > > of identity in SDO, and its relationship to other technologies.
> > > >
> > > > Database IDs (e.g., primary and foreign keys) are more related to
> > > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
>
> > > > to address all of them :-)
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > > >
> > > > > Hi Frank,
> > > > > Thanks.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > >
> > > > > That is good news. However, identity mechanics should appear
> > > > > more distinctly on API surface e.g.
> > > > > boolean Proprty.isIdentifier();
> > > > > List<Property> Type.getIdentifiers();
> > > > >
> > > > > I will qualify absence of any identity semantics from SDO a
> > > > > major drawback. Especially, if it comes to any persistence
> > > > > operation on SDO DataObject/DataGraph. Hopefully some of the SDO
>
> > > > > spec writers would notice this omission and add it to future
> spec version.
> > > > >
> > > > > After a quick pick in current DAS implementation, it appeared
> > > > > that
> >
> > > > > 'primary key' identification is based on existing database
> > > > > column name
> > > >
> > > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > > learn how DAS is handling identity issue.
> > > > >
> > > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > > extended
> >
> > > > > > XSD
> > > > > metadata
> > > > > That is a good decision. Wrapping should always provide access
> > > > > to what
> > > >
> > > > > is being wrapped.
> > > > >
> > > > > > downcasting to the EMF implementation class
> > > > >
> > > > > Thanks for this info. I will do this for now. But I heed your
> > > > > advice
> > >
> > > > > and have already a scheme in place that programs against *only*
> > > > > commonj.sdo API but can access underlying implementaion, if
> > > > > available,
> > > >
> > > > > without any compile-time binding.
> > > > > Slightly costly -- but works for, say, extracting package name
> > > > > from Types.
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > > To: tuscany-dev@ws.apache.org
> > > > > Subject: Re: How does xsd:ID property type is distinguished from
>
> > > > > xsd:string
> > > > >
> > > > > Hi Pinaki,
> > > > >
> > > > > They can't be distinguished in the current version of SDO
> > > > > metadata, you need to look at the original XSD. The next version
>
> > > > > of SDO (SDO
> > > > > 3) is planning to provide an api for accessing extended XSD
> > > > > metadata. In Tuscany, you can currently determine this by
> > > > > downcasting to the EMF implementation class, although we don't
> > > recommend people do that:
> > > > >
> > > > > System.out.println(" Property isID: " +
> > > > > ((property.getType().isDataType()) &&
> > > > > ((EAttribute)property).isID()));
> > > > >
> > > > > Frank.
> > > > >
> > > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
> AM:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > A newbie question:
> > > > > > How does two Property: one defined as xsd:string and other
> > > > > > as
> >
> > > > > > xsd:ID can be distiguished?
> > > > > >
> > > > > > Assume:
> > > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > > with two properties as follows:
> > > > > > <xsd:complexType name="Person">
> > > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > 2. TypeHelper.INSTANCE.define()
> > > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > > firstName)
> > > > >
> > > > > > and p2 (for id)
> > > > > >
> > > > > > 3. both p1.getType().getInstanceClass() and
> > > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > > both p1.getType().isDataType() and
> > > > > > p2.getType().isDataType()
> >
> > > > > > return true
> > > > > >
> > > > > > The question is, what can be done to identify p2 as a property
>
> > > > > > that were defined as xsd:ID?
> > > > > >
> > > > > >
> > > > > > Thanks for your help --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pinaki Poddar
> > > > > > 972.834.2865
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > --------------------------------------------------------------
> > > > > > --
> > > > > > --
> > > > > > --
> > > > > > - To unsubscribe, e-mail:
> > > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > tuscany-dev-help@ws.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Luciano,
In an earlier response to your question:
> if would be feasible to add a DAS interface[1] layer on top of Fluid
[2]?
My answer was: Yes.
As backup of that answer, I just added the support for SDO DAS by
implementing DASFactory/DAS/Command
Using Fluid. These implementations are very thin-wrapper that delegates
to Fluid's JPA API.
From a usage model, there is conceptual shift though from a SQL-based
DAS.
Using Fluid based DAS, user code will look like: (there are some
TestCases that details it)
DataObject person = createPerson(ssn, "Fluid", "Guy",
17);
DAS das = getDAS();
Command insert = das.getCommand("INSERT");
insert.setParameter(0, person);
insert.execute();
to persist a Person DataObject, or to query
DAS das = getDAS();
Command query = das.getCommand("SELECT");
String jpql = "SELECT o FROM Person o WHERE
o.firstName=?1 AND o.age=?2";
query.setParameter(0, jpql);
query.setParameter(1, "Fluid");
query.setParameter(2, 17);
DataObject list = query.executeQuery();
List result = (List)list.get(0);
Few notable points are:
1. There is no SQL.
2. All object level paramaters are set via Command.setParameter()
method.
Insert command acts on a Person DataObject (insert can be cascaded
transitively, btw)
which is passed to it as parameter.
3. Query is JPQL. This is a powerful contribution of JPA. The
namespace of the query
tokens are Object Domain tokens i.e. SDO Type and Property names;
not database
Table or Column names. Join is navigation across a SDO DataGraph.
OpenJPA will take care of creating the appropriate SQL.
User can see/monitor what SQL is being generated by OpenJPA.
4. DAS defined return of Command.executeQuery() as a DataObject. One
would prefer it
to be a List<DataObject> but to confirm to the API, I just return a
dynamic DataObject
whose 0-th Property is a List<DataObject>
And, last but not the least, applyChanges():
dataObject.setString("firstName", "Solid");
das.applyChanges(dataObject);
Will make an UPDATE to the database.
How does user application gets a DAS?
DASFactory dasFactory = new FluidDASFactory("SDO-DAS");
DAS dasFactory = dasfactory.createDAS();
1. Everything about persistence service (from database connections to
~200 configurable parameters
supported by OpenJPA) is configured in a single file:
META-INF/persistence.xml.
The unit name in this file should be <persistence-unit
unitName="SDO-DAS">.
2. The overloaded DASFactory.createDAS() that takes
org.apache.tuscany.sdo.das.rdb.Config and other
parameters are supported simply by ignoring the argument :).
Regards
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Friday, July 27, 2007 3:25 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA
I haven't looked into this with any great detail, but I'd like to ask if
would be feasible to add a DAS interface[1] layer on top of Fluid [2].
Thoughts ?
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main
/java/org/apache/tuscany/das/rdb/DAS.java
[2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> Hi Pinaki,
>
> I think your project has a lot of potential. Another related aspect is
> that there is interest in the SDO specification charter to discuss the
> possibility of converging/supporting JAXB with static SDO in version
3.
> JAXB2, as you may know, has a similar objective to support standard
POJOs.
> If that happens, then I see even more synergy with your approach. At
> Tuscany, we'd also be very interested in the bytecode generation that
> you mentioned you've prototyped in Fluid. Tuscany has done a little
> bit of sandbox prototyping in that area as well, but nobody has had
> enough time to really pursue it.
>
> Given this work, I think you should consider getting involved with the
> DAS specification effort, if you haven't already.
>
> Frank.
>
>
>
>
> "Pinaki Poddar" <pp...@bea.com>
> 07/27/2007 12:32 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
> <de...@openjpa.apache.org>
> Subject
> Persistence of Service Data Objects using OpenJPA
>
>
>
>
>
>
> Hi Frank,
>
> Thank you for your interest. Before I answer the specific questions
> let me say few words to explain why Fluid is attempted at first place.
>
> A) there is a natural synergy between SDO model and the POJO model
> where JPA excels.
> B) Object Persistence (be it strongly-typed POJO or loosely-typed
> SDO) is complex problem by itself. Throw in quirk of multiple database
> vendors -- and one really got a hard problem in hand. OpenJPA,
> Hibernate, TopLink had worked over many years to solve this problem to
> a reasonable degree. SDO persistence should leverage that
> knowledge/effort instead of reinventing a costly wheel.
>
>
> 1) Yes -- you're right. The views expressed in
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29 is in agreement with what promoted me to start the lab
> (actually I checked this page while researching and mentioned in in my
> blog). According to this wiki page: "Work on the specification of a
> JPA data access service by the OSOA collaboration is envisaged
> sometime in the future but has not started yet."
> So Fluid can be considered as a prototype/exploration of similar
> ideas.
>
> 2) Yes, I am aware of SDO's generation of Java and I have played with
> org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided
> to write yet another code generator for Fluid because
>
> a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> Type information defined by XSDHelper.define().
> The annotations in the class will be made optional as we proceed --
> because JPA allows a separate mapping file Orm.xml thereby retaining
> POJO-ness of the persistent domain classes.
>
> b) The generated Java classes is "domain-ready" i.e. they are
> self-consistent and independent. Proof: they can be compiled without
> any other package other that java.util.*. Adding annotation, however,
> makes them compile-dependent on jpa.jar, but that dependency will be
> made optional as mapping information can be externalized in orm.xml.
>
> C) as far as SDO metamodel to Java metamodel mapping goes, it is
> essentially isomorphic (at least for this prototype).
> SDO2POJO does not introduce any extra artifact (see below). I have not
> played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> to make a fair judgement -- but most probably it is generating Java
> classes which has more dependency on framework classes in terms of
> (inheriting/implementing) as well as package imports.
>
> d) One mapping element is introduced in SDO-Java conversion
process.
> It is about "Container" SDO Types. I describe the details in Fluid
> website. The reason for defining a Container Type abstraction is
> better alignment for mapping to relational database (save extra joins
> and allow navigational query across multi-cardinality relation paths).
>
>
> 3) Besides the source code generation route, another possibilities
> is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> that approach too.
>
> Regards --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Friday, July 27, 2007 10:39 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> Hi Pinaki,
>
> This looks very cool, especially that you've got a working prototype!
> I have a couple of questions.
>
> 1) This seems to overlap with the DAS plan described here:
>
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29
>
> I'm not very familiar with the DAS work myself, but there seems to be
> some overlap with your work.
>
> 2) I'm also wondering if you were aware that SDO also defines a
> mapping to static Java interfaces/classes. See section 5 of the SDO
spec:
>
>
> http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL
> .p
> df?version=1
>
> Does your SDO2POJOGenerator conform to that mapping? Have you tried
> the Tuscany static SDO generator
> (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> relashionship?
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
>
> > Hello,
> > I have been asking newbie questions to this forum. And people have
> > been very helpful.
> >
> > Those newbie questions were for a Apache Lab project named Fluid
> > -- to explore possibilities of SDO persistence using JPA API.
> >
> > With all your help, I could put together an initial proptotype
> > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > OpenJPA for SDO and JPA implementation respectively.
> >
> > Further details of this project (with user documentation) can be
> > found at
> >
> > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> >
> > Your comments/suggestions are most welcome --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 4:59 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > EAttribute.isID() will only be true if the type is xsd:ID.
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> >
> > > Hi Frank,
> > > > Database IDs (e.g., primary and foreign keys) are more
> > > related to
> >
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Thanks for telling me this.
> > >
> > > Now is ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID())) == true for a property p that is
> > > declared as xsd:key or xsd:keyref?
> > >
> > > Or broadly, what is the semantics of Eattribute.isID()?
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > Identity support is also in the SDO 3 charter: Support for a
> > > concept
>
> > > of identity in SDO, and its relationship to other technologies.
> > >
> > > Database IDs (e.g., primary and foreign keys) are more related to
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > >
> > > > Hi Frank,
> > > > Thanks.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > >
> > > > That is good news. However, identity mechanics should appear
> > > > more distinctly on API surface e.g.
> > > > boolean Proprty.isIdentifier();
> > > > List<Property> Type.getIdentifiers();
> > > >
> > > > I will qualify absence of any identity semantics from SDO a
> > > > major drawback. Especially, if it comes to any persistence
> > > > operation on SDO DataObject/DataGraph. Hopefully some of the SDO
> > > > spec writers would notice this omission and add it to future
spec version.
> > > >
> > > > After a quick pick in current DAS implementation, it appeared
> > > > that
>
> > > > 'primary key' identification is based on existing database
> > > > column name
> > >
> > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > learn how DAS is handling identity issue.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > > That is a good decision. Wrapping should always provide access
> > > > to what
> > >
> > > > is being wrapped.
> > > >
> > > > > downcasting to the EMF implementation class
> > > >
> > > > Thanks for this info. I will do this for now. But I heed your
> > > > advice
> >
> > > > and have already a scheme in place that programs against *only*
> > > > commonj.sdo API but can access underlying implementaion, if
> > > > available,
> > >
> > > > without any compile-time binding.
> > > > Slightly costly -- but works for, say, extracting package name
> > > > from Types.
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > They can't be distinguished in the current version of SDO
> > > > metadata, you need to look at the original XSD. The next version
> > > > of SDO (SDO
> > > > 3) is planning to provide an api for accessing extended XSD
> > > > metadata. In Tuscany, you can currently determine this by
> > > > downcasting to the EMF implementation class, although we don't
> > recommend people do that:
> > > >
> > > > System.out.println(" Property isID: " +
> > > > ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID()));
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
AM:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > A newbie question:
> > > > > How does two Property: one defined as xsd:string and other
> > > > > as
>
> > > > > xsd:ID can be distiguished?
> > > > >
> > > > > Assume:
> > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > with two properties as follows:
> > > > > <xsd:complexType name="Person">
> > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > 2. TypeHelper.INSTANCE.define()
> > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > firstName)
> > > >
> > > > > and p2 (for id)
> > > > >
> > > > > 3. both p1.getType().getInstanceClass() and
> > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > both p1.getType().isDataType() and
> > > > > p2.getType().isDataType()
>
> > > > > return true
> > > > >
> > > > > The question is, what can be done to identify p2 as a property
> > > > > that were defined as xsd:ID?
> > > > >
> > > > >
> > > > > Thanks for your help --
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > 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.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Luciano,
In an earlier response to your question:
> if would be feasible to add a DAS interface[1] layer on top of Fluid
[2]?
My answer was: Yes.
As backup of that answer, I just added the support for SDO DAS by
implementing DASFactory/DAS/Command
Using Fluid. These implementations are very thin-wrapper that delegates
to Fluid's JPA API.
From a usage model, there is conceptual shift though from a SQL-based
DAS.
Using Fluid based DAS, user code will look like: (there are some
TestCases that details it)
DataObject person = createPerson(ssn, "Fluid", "Guy",
17);
DAS das = getDAS();
Command insert = das.getCommand("INSERT");
insert.setParameter(0, person);
insert.execute();
to persist a Person DataObject, or to query
DAS das = getDAS();
Command query = das.getCommand("SELECT");
String jpql = "SELECT o FROM Person o WHERE
o.firstName=?1 AND o.age=?2";
query.setParameter(0, jpql);
query.setParameter(1, "Fluid");
query.setParameter(2, 17);
DataObject list = query.executeQuery();
List result = (List)list.get(0);
Few notable points are:
1. There is no SQL.
2. All object level paramaters are set via Command.setParameter()
method.
Insert command acts on a Person DataObject (insert can be cascaded
transitively, btw)
which is passed to it as parameter.
3. Query is JPQL. This is a powerful contribution of JPA. The
namespace of the query
tokens are Object Domain tokens i.e. SDO Type and Property names;
not database
Table or Column names. Join is navigation across a SDO DataGraph.
OpenJPA will take care of creating the appropriate SQL.
User can see/monitor what SQL is being generated by OpenJPA.
4. DAS defined return of Command.executeQuery() as a DataObject. One
would prefer it
to be a List<DataObject> but to confirm to the API, I just return a
dynamic DataObject
whose 0-th Property is a List<DataObject>
And, last but not the least, applyChanges():
dataObject.setString("firstName", "Solid");
das.applyChanges(dataObject);
Will make an UPDATE to the database.
How does user application gets a DAS?
DASFactory dasFactory = new FluidDASFactory("SDO-DAS");
DAS dasFactory = dasfactory.createDAS();
1. Everything about persistence service (from database connections to
~200 configurable parameters
supported by OpenJPA) is configured in a single file:
META-INF/persistence.xml.
The unit name in this file should be <persistence-unit
unitName="SDO-DAS">.
2. The overloaded DASFactory.createDAS() that takes
org.apache.tuscany.sdo.das.rdb.Config and other
parameters are supported simply by ignoring the argument :).
Regards
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Friday, July 27, 2007 3:25 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA
I haven't looked into this with any great detail, but I'd like to ask if
would be feasible to add a DAS interface[1] layer on top of Fluid [2].
Thoughts ?
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main
/java/org/apache/tuscany/das/rdb/DAS.java
[2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> Hi Pinaki,
>
> I think your project has a lot of potential. Another related aspect is
> that there is interest in the SDO specification charter to discuss the
> possibility of converging/supporting JAXB with static SDO in version
3.
> JAXB2, as you may know, has a similar objective to support standard
POJOs.
> If that happens, then I see even more synergy with your approach. At
> Tuscany, we'd also be very interested in the bytecode generation that
> you mentioned you've prototyped in Fluid. Tuscany has done a little
> bit of sandbox prototyping in that area as well, but nobody has had
> enough time to really pursue it.
>
> Given this work, I think you should consider getting involved with the
> DAS specification effort, if you haven't already.
>
> Frank.
>
>
>
>
> "Pinaki Poddar" <pp...@bea.com>
> 07/27/2007 12:32 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
> <de...@openjpa.apache.org>
> Subject
> Persistence of Service Data Objects using OpenJPA
>
>
>
>
>
>
> Hi Frank,
>
> Thank you for your interest. Before I answer the specific questions
> let me say few words to explain why Fluid is attempted at first place.
>
> A) there is a natural synergy between SDO model and the POJO model
> where JPA excels.
> B) Object Persistence (be it strongly-typed POJO or loosely-typed
> SDO) is complex problem by itself. Throw in quirk of multiple database
> vendors -- and one really got a hard problem in hand. OpenJPA,
> Hibernate, TopLink had worked over many years to solve this problem to
> a reasonable degree. SDO persistence should leverage that
> knowledge/effort instead of reinventing a costly wheel.
>
>
> 1) Yes -- you're right. The views expressed in
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29 is in agreement with what promoted me to start the lab
> (actually I checked this page while researching and mentioned in in my
> blog). According to this wiki page: "Work on the specification of a
> JPA data access service by the OSOA collaboration is envisaged
> sometime in the future but has not started yet."
> So Fluid can be considered as a prototype/exploration of similar
> ideas.
>
> 2) Yes, I am aware of SDO's generation of Java and I have played with
> org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided
> to write yet another code generator for Fluid because
>
> a) SDO2POJOGenerator handles JPA annotations as it sources SDO
> Type information defined by XSDHelper.define().
> The annotations in the class will be made optional as we proceed --
> because JPA allows a separate mapping file Orm.xml thereby retaining
> POJO-ness of the persistent domain classes.
>
> b) The generated Java classes is "domain-ready" i.e. they are
> self-consistent and independent. Proof: they can be compiled without
> any other package other that java.util.*. Adding annotation, however,
> makes them compile-dependent on jpa.jar, but that dependency will be
> made optional as mapping information can be externalized in orm.xml.
>
> C) as far as SDO metamodel to Java metamodel mapping goes, it is
> essentially isomorphic (at least for this prototype).
> SDO2POJO does not introduce any extra artifact (see below). I have not
> played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> to make a fair judgement -- but most probably it is generating Java
> classes which has more dependency on framework classes in terms of
> (inheriting/implementing) as well as package imports.
>
> d) One mapping element is introduced in SDO-Java conversion
process.
> It is about "Container" SDO Types. I describe the details in Fluid
> website. The reason for defining a Container Type abstraction is
> better alignment for mapping to relational database (save extra joins
> and allow navigational query across multi-cardinality relation paths).
>
>
> 3) Besides the source code generation route, another possibilities
> is dynamic Java bytecode generation for SDO Types. Fluid prototyped
> that approach too.
>
> Regards --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Friday, July 27, 2007 10:39 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> Hi Pinaki,
>
> This looks very cool, especially that you've got a working prototype!
> I have a couple of questions.
>
> 1) This seems to overlap with the DAS plan described here:
>
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture
> +%
> 28JPA%29
>
> I'm not very familiar with the DAS work myself, but there seems to be
> some overlap with your work.
>
> 2) I'm also wondering if you were aware that SDO also defines a
> mapping to static Java interfaces/classes. See section 5 of the SDO
spec:
>
>
> http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL
> .p
> df?version=1
>
> Does your SDO2POJOGenerator conform to that mapping? Have you tried
> the Tuscany static SDO generator
> (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> relashionship?
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
>
> > Hello,
> > I have been asking newbie questions to this forum. And people have
> > been very helpful.
> >
> > Those newbie questions were for a Apache Lab project named Fluid
> > -- to explore possibilities of SDO persistence using JPA API.
> >
> > With all your help, I could put together an initial proptotype
> > that creates/updates/queries SDO using JPA API. I used Tuscany and
> > OpenJPA for SDO and JPA implementation respectively.
> >
> > Further details of this project (with user documentation) can be
> > found at
> >
> > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> >
> > Your comments/suggestions are most welcome --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 4:59 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > EAttribute.isID() will only be true if the type is xsd:ID.
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> >
> > > Hi Frank,
> > > > Database IDs (e.g., primary and foreign keys) are more
> > > related to
> >
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Thanks for telling me this.
> > >
> > > Now is ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID())) == true for a property p that is
> > > declared as xsd:key or xsd:keyref?
> > >
> > > Or broadly, what is the semantics of Eattribute.isID()?
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > Identity support is also in the SDO 3 charter: Support for a
> > > concept
>
> > > of identity in SDO, and its relationship to other technologies.
> > >
> > > Database IDs (e.g., primary and foreign keys) are more related to
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > >
> > > > Hi Frank,
> > > > Thanks.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > >
> > > > That is good news. However, identity mechanics should appear
> > > > more distinctly on API surface e.g.
> > > > boolean Proprty.isIdentifier();
> > > > List<Property> Type.getIdentifiers();
> > > >
> > > > I will qualify absence of any identity semantics from SDO a
> > > > major drawback. Especially, if it comes to any persistence
> > > > operation on SDO DataObject/DataGraph. Hopefully some of the SDO
> > > > spec writers would notice this omission and add it to future
spec version.
> > > >
> > > > After a quick pick in current DAS implementation, it appeared
> > > > that
>
> > > > 'primary key' identification is based on existing database
> > > > column name
> > >
> > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to
> > > > learn how DAS is handling identity issue.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing
> > > > > extended
>
> > > > > XSD
> > > > metadata
> > > > That is a good decision. Wrapping should always provide access
> > > > to what
> > >
> > > > is being wrapped.
> > > >
> > > > > downcasting to the EMF implementation class
> > > >
> > > > Thanks for this info. I will do this for now. But I heed your
> > > > advice
> >
> > > > and have already a scheme in place that programs against *only*
> > > > commonj.sdo API but can access underlying implementaion, if
> > > > available,
> > >
> > > > without any compile-time binding.
> > > > Slightly costly -- but works for, say, extracting package name
> > > > from Types.
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > They can't be distinguished in the current version of SDO
> > > > metadata, you need to look at the original XSD. The next version
> > > > of SDO (SDO
> > > > 3) is planning to provide an api for accessing extended XSD
> > > > metadata. In Tuscany, you can currently determine this by
> > > > downcasting to the EMF implementation class, although we don't
> > recommend people do that:
> > > >
> > > > System.out.println(" Property isID: " +
> > > > ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID()));
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03
AM:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > A newbie question:
> > > > > How does two Property: one defined as xsd:string and other
> > > > > as
>
> > > > > xsd:ID can be distiguished?
> > > > >
> > > > > Assume:
> > > > > 1. we have a simple XML schema defining a Person SDO Type
> > > > > with two properties as follows:
> > > > > <xsd:complexType name="Person">
> > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > 2. TypeHelper.INSTANCE.define()
> > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > firstName)
> > > >
> > > > > and p2 (for id)
> > > > >
> > > > > 3. both p1.getType().getInstanceClass() and
> > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > both p1.getType().isDataType() and
> > > > > p2.getType().isDataType()
>
> > > > > return true
> > > > >
> > > > > The question is, what can be done to identify p2 as a property
> > > > > that were defined as xsd:ID?
> > > > >
> > > > >
> > > > > Thanks for your help --
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > 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.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail:
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail:
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
Re: Persistence of Service Data Objects using OpenJPA
Posted by Luciano Resende <lu...@gmail.com>.
I haven't looked into this with any great detail, but I'd like to ask
if would be feasible to add a DAS interface[1] layer on top of Fluid
[2].
Thoughts ?
[1] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/DAS.java
[2] http://people.apache.org/~ppoddar/fluid/site/welcome.html
On 7/27/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
> Hi Pinaki,
>
> I think your project has a lot of potential. Another related aspect is
> that there is interest in the SDO specification charter to discuss the
> possibility of converging/supporting JAXB with static SDO in version 3.
> JAXB2, as you may know, has a similar objective to support standard POJOs.
> If that happens, then I see even more synergy with your approach. At
> Tuscany, we'd also be very interested in the bytecode generation that you
> mentioned you've prototyped in Fluid. Tuscany has done a little bit of
> sandbox prototyping in that area as well, but nobody has had enough time
> to really pursue it.
>
> Given this work, I think you should consider getting involved with the DAS
> specification effort, if you haven't already.
>
> Frank.
>
>
>
>
> "Pinaki Poddar" <pp...@bea.com>
> 07/27/2007 12:32 PM
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> <tu...@ws.apache.org>
> cc
> <de...@openjpa.apache.org>
> Subject
> Persistence of Service Data Objects using OpenJPA
>
>
>
>
>
>
> Hi Frank,
>
> Thank you for your interest. Before I answer the specific questions
> let me say few words to explain why Fluid is attempted at first place.
>
> A) there is a natural synergy between SDO model and the POJO model
> where JPA excels.
> B) Object Persistence (be it strongly-typed POJO or loosely-typed
> SDO) is complex problem by itself. Throw in quirk of multiple database
> vendors -- and one really got a hard problem in hand. OpenJPA,
> Hibernate, TopLink had worked over many years to solve this problem to a
> reasonable degree. SDO persistence should leverage that knowledge/effort
> instead of reinventing a costly wheel.
>
>
> 1) Yes -- you're right. The views expressed in
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
> 28JPA%29 is in agreement with what promoted me to start the lab
> (actually I checked this page while researching and mentioned in in my
> blog). According to this wiki page: "Work on the specification of a JPA
> data access service by the OSOA collaboration is envisaged sometime in
> the future but has not started yet."
> So Fluid can be considered as a prototype/exploration of similar
> ideas.
>
> 2) Yes, I am aware of SDO's generation of Java and I have played with
> org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to
> write yet another code generator for Fluid because
>
> a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type
> information defined by XSDHelper.define().
> The annotations in the class will be made optional as we proceed --
> because JPA allows a separate mapping file
> Orm.xml thereby retaining POJO-ness of the persistent domain classes.
>
> b) The generated Java classes is "domain-ready" i.e. they are
> self-consistent and independent. Proof: they can
> be compiled without any other package other that java.util.*. Adding
> annotation, however, makes them compile-dependent on jpa.jar, but that
> dependency will be made optional as mapping information can be
> externalized in orm.xml.
>
> C) as far as SDO metamodel to Java metamodel mapping goes, it is
> essentially isomorphic (at least for this prototype).
> SDO2POJO does not introduce any extra artifact (see below). I have not
> played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to
> make a fair judgement -- but most probably it is generating Java classes
> which has more dependency on framework classes in terms of
> (inheriting/implementing) as well as package imports.
>
> d) One mapping element is introduced in SDO-Java conversion process.
> It is about "Container" SDO Types. I describe the details in Fluid
> website. The reason for defining a Container Type abstraction is better
> alignment for mapping to relational database (save extra joins and allow
> navigational query across multi-cardinality relation paths).
>
>
> 3) Besides the source code generation route, another possibilities is
> dynamic Java bytecode generation for SDO Types. Fluid prototyped that
> approach too.
>
> Regards --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Friday, July 27, 2007 10:39 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> Hi Pinaki,
>
> This looks very cool, especially that you've got a working prototype! I
> have a couple of questions.
>
> 1) This seems to overlap with the DAS plan described here:
>
>
> http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
> 28JPA%29
>
> I'm not very familiar with the DAS work myself, but there seems to be
> some overlap with your work.
>
> 2) I'm also wondering if you were aware that SDO also defines a mapping
> to static Java interfaces/classes. See section 5 of the SDO spec:
>
>
> http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p
> df?version=1
>
> Does your SDO2POJOGenerator conform to that mapping? Have you tried the
> Tuscany static SDO generator
> (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
> relashionship?
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
>
> > Hello,
> > I have been asking newbie questions to this forum. And people have
> > been very helpful.
> >
> > Those newbie questions were for a Apache Lab project named Fluid --
> > to explore possibilities of SDO persistence using JPA API.
> >
> > With all your help, I could put together an initial proptotype that
> > creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA
> > for SDO and JPA implementation respectively.
> >
> > Further details of this project (with user documentation) can be
> > found at
> >
> > http://people.apache.org/~ppoddar/fluid/site/welcome.html
> >
> > Your comments/suggestions are most welcome --
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 4:59 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > EAttribute.isID() will only be true if the type is xsd:ID.
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
> >
> > > Hi Frank,
> > > > Database IDs (e.g., primary and foreign keys) are more related
> > > to
> >
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Thanks for telling me this.
> > >
> > > Now is ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID())) == true for a property p that is
> > > declared as xsd:key or xsd:keyref?
> > >
> > > Or broadly, what is the semantics of Eattribute.isID()?
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 3:01 PM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > Identity support is also in the SDO 3 charter: Support for a concept
>
> > > of identity in SDO, and its relationship to other technologies.
> > >
> > > Database IDs (e.g., primary and foreign keys) are more related to
> > > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > > to address all of them :-)
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> > >
> > > > Hi Frank,
> > > > Thanks.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing extended
>
> > > > > XSD
> > > > metadata
> > > >
> > > > That is good news. However, identity mechanics should appear
> > > > more distinctly on API surface e.g.
> > > > boolean Proprty.isIdentifier();
> > > > List<Property> Type.getIdentifiers();
> > > >
> > > > I will qualify absence of any identity semantics from SDO a major
> > > > drawback. Especially, if it comes to any persistence operation on
> > > > SDO DataObject/DataGraph. Hopefully some of the SDO spec writers
> > > > would notice this omission and add it to future spec version.
> > > >
> > > > After a quick pick in current DAS implementation, it appeared that
>
> > > > 'primary key' identification is based on existing database column
> > > > name
> > >
> > > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to learn
> > > > how DAS is handling identity issue.
> > > >
> > > > > SDO (SDO 3) is planning to provide an api for accessing extended
>
> > > > > XSD
> > > > metadata
> > > > That is a good decision. Wrapping should always provide access to
> > > > what
> > >
> > > > is being wrapped.
> > > >
> > > > > downcasting to the EMF implementation class
> > > >
> > > > Thanks for this info. I will do this for now. But I heed your
> > > > advice
> >
> > > > and have already a scheme in place that programs against *only*
> > > > commonj.sdo API but can access underlying implementaion, if
> > > > available,
> > >
> > > > without any compile-time binding.
> > > > Slightly costly -- but works for, say, extracting package name
> > > > from Types.
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: How does xsd:ID property type is distinguished from
> > > > xsd:string
> > > >
> > > > Hi Pinaki,
> > > >
> > > > They can't be distinguished in the current version of SDO
> > > > metadata, you need to look at the original XSD. The next version
> > > > of SDO (SDO
> > > > 3) is planning to provide an api for accessing extended XSD
> > > > metadata. In Tuscany, you can currently determine this by
> > > > downcasting to the EMF implementation class, although we don't
> > recommend people do that:
> > > >
> > > > System.out.println(" Property isID: " +
> > > > ((property.getType().isDataType()) &&
> > > > ((EAttribute)property).isID()));
> > > >
> > > > Frank.
> > > >
> > > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03 AM:
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > A newbie question:
> > > > > How does two Property: one defined as xsd:string and other as
>
> > > > > xsd:ID can be distiguished?
> > > > >
> > > > > Assume:
> > > > > 1. we have a simple XML schema defining a Person SDO Type with
> > > > > two properties as follows:
> > > > > <xsd:complexType name="Person">
> > > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > > </xsd:complexType>
> > > > >
> > > > > 2. TypeHelper.INSTANCE.define()
> > > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > > firstName)
> > > >
> > > > > and p2 (for id)
> > > > >
> > > > > 3. both p1.getType().getInstanceClass() and
> > > > > p2.getType().getInstanceClass() return java.lang.String
> > > > > both p1.getType().isDataType() and p2.getType().isDataType()
>
> > > > > return true
> > > > >
> > > > > The question is, what can be done to identify p2 as a property
> > > > > that were defined as xsd:ID?
> > > > >
> > > > >
> > > > > Thanks for your help --
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Pinaki Poddar
> > > > > 972.834.2865
> > > > >
> > > > > 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.
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > > 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.
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Persistence of Service Data Objects using OpenJPA
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Frank,
> I think your project has a lot of potential.
Thank you for your encouraging words.
> JAXB with static SDO in version 3. JAXB2, as you may know, has a
similar objective to support standard POJOs.
> If that happens, then I see even more synergy with your approach.
Yes -- though Fluid only begins with SDO -- but the idea is to explore
extending OpenJPA (that is originally designed to handle strongly-typed
meta systems) for relaxed-type meta systsms. So that SDO, XML document
and data from other loosely-typed systems can leverage significant
features of JPA. This brings us to the question:
How the "other" type system is mapped to strongly-typed Java domain
that JPA can handle?
The mechanics of such mapping can be delegated to JAXB provided it
does not introduce its own artifact in the generation process. Because
the target domain object that JPA will handle is better to be POJO
(restoring that POJO nature from under heavyweight EJB framework had
been a long battle :).
Fluid prototype skips the question by degenarting SDO-Java mapping to
isomorphic case and writing a SDO2POJOGenerator in few lines.
> At Tuscany, we'd also be very interested in the bytecode generation
that you mentioned you've prototyped in Fluid. Tuscany has done a little
bit of sandbox prototyping in that area as well, but nobody has had
enough time to really pursue it.
Bytecode generation is feasible, powerful and difficult to maintain.
OpenJPA uses bytecode generation with SERP (http://serp.sourceforge.net/
written by one of the architects of OpenJPA) library extensively as a
post-compilation process known as enhancement. Powerful and neat it is,
but, enhanement has often been seen as 'barrier-to-entry' by the
critics.
Moreover, from O-O mapping standpoint -- an intermediate Java source
code + plus a mapping specs is perhaps a more maintainable and
comprehensible route than magical, dynamic bytecode generation.
In Fluid source codebase org.apache.openjpa.sdo.SDOTypeRepostory has
the bytecode generation code. It is not activated though.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 2:59 PM
To: tuscany-dev@ws.apache.org
Cc: dev@openjpa.apache.org
Subject: Re: Persistence of Service Data Objects using OpenJPA
Hi Pinaki,
I think your project has a lot of potential. Another related aspect is
that there is interest in the SDO specification charter to discuss the
possibility of converging/supporting JAXB with static SDO in version 3.
JAXB2, as you may know, has a similar objective to support standard
POJOs.
If that happens, then I see even more synergy with your approach. At
Tuscany, we'd also be very interested in the bytecode generation that
you mentioned you've prototyped in Fluid. Tuscany has done a little bit
of sandbox prototyping in that area as well, but nobody has had enough
time to really pursue it.
Given this work, I think you should consider getting involved with the
DAS specification effort, if you haven't already.
Frank.
"Pinaki Poddar" <pp...@bea.com>
07/27/2007 12:32 PM
Please respond to
tuscany-dev@ws.apache.org
To
<tu...@ws.apache.org>
cc
<de...@openjpa.apache.org>
Subject
Persistence of Service Data Objects using OpenJPA
Hi Frank,
Thank you for your interest. Before I answer the specific questions
let me say few words to explain why Fluid is attempted at first place.
A) there is a natural synergy between SDO model and the POJO model
where JPA excels.
B) Object Persistence (be it strongly-typed POJO or loosely-typed
SDO) is complex problem by itself. Throw in quirk of multiple database
vendors -- and one really got a hard problem in hand. OpenJPA,
Hibernate, TopLink had worked over many years to solve this problem to a
reasonable degree. SDO persistence should leverage that knowledge/effort
instead of reinventing a costly wheel.
1) Yes -- you're right. The views expressed in
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29 is in agreement with what promoted me to start the lab
(actually I checked this page while researching and mentioned in in my
blog). According to this wiki page: "Work on the specification of a JPA
data access service by the OSOA collaboration is envisaged sometime in
the future but has not started yet."
So Fluid can be considered as a prototype/exploration of similar
ideas.
2) Yes, I am aware of SDO's generation of Java and I have played with
org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to
write yet another code generator for Fluid because
a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type
information defined by XSDHelper.define().
The annotations in the class will be made optional as we proceed --
because JPA allows a separate mapping file
Orm.xml thereby retaining POJO-ness of the persistent domain classes.
b) The generated Java classes is "domain-ready" i.e. they are
self-consistent and independent. Proof: they can
be compiled without any other package other that java.util.*. Adding
annotation, however, makes them compile-dependent on jpa.jar, but that
dependency will be made optional as mapping information can be
externalized in orm.xml.
C) as far as SDO metamodel to Java metamodel mapping goes, it is
essentially isomorphic (at least for this prototype).
SDO2POJO does not introduce any extra artifact (see below). I have not
played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to
make a fair judgement -- but most probably it is generating Java classes
which has more dependency on framework classes in terms of
(inheriting/implementing) as well as package imports.
d) One mapping element is introduced in SDO-Java conversion process.
It is about "Container" SDO Types. I describe the details in Fluid
website. The reason for defining a Container Type abstraction is better
alignment for mapping to relational database (save extra joins and allow
navigational query across multi-cardinality relation paths).
3) Besides the source code generation route, another possibilities is
dynamic Java bytecode generation for SDO Types. Fluid prototyped that
approach too.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 10:39 AM
To: tuscany-dev@ws.apache.org
Subject: RE: How does xsd:ID property type is distinguished from
xsd:string
Hi Pinaki,
This looks very cool, especially that you've got a working prototype! I
have a couple of questions.
1) This seems to overlap with the DAS plan described here:
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29
I'm not very familiar with the DAS work myself, but there seems to be
some overlap with your work.
2) I'm also wondering if you were aware that SDO also defines a mapping
to static Java interfaces/classes. See section 5 of the SDO spec:
http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p
df?version=1
Does your SDO2POJOGenerator conform to that mapping? Have you tried the
Tuscany static SDO generator
(org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
relashionship?
Frank.
"Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> Hello,
> I have been asking newbie questions to this forum. And people have
> been very helpful.
>
> Those newbie questions were for a Apache Lab project named Fluid --
> to explore possibilities of SDO persistence using JPA API.
>
> With all your help, I could put together an initial proptotype that
> creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA
> for SDO and JPA implementation respectively.
>
> Further details of this project (with user documentation) can be
> found at
>
> http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> Your comments/suggestions are most welcome --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Tuesday, July 24, 2007 4:59 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> EAttribute.isID() will only be true if the type is xsd:ID.
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
>
> > Hi Frank,
> > > Database IDs (e.g., primary and foreign keys) are more related
> > to
>
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Thanks for telling me this.
> >
> > Now is ((property.getType().isDataType()) &&
> > ((EAttribute)property).isID())) == true for a property p that is
> > declared as xsd:key or xsd:keyref?
> >
> > Or broadly, what is the semantics of Eattribute.isID()?
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 3:01 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > Identity support is also in the SDO 3 charter: Support for a concept
> > of identity in SDO, and its relationship to other technologies.
> >
> > Database IDs (e.g., primary and foreign keys) are more related to
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> >
> > > Hi Frank,
> > > Thanks.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > >
> > > That is good news. However, identity mechanics should appear
> > > more distinctly on API surface e.g.
> > > boolean Proprty.isIdentifier();
> > > List<Property> Type.getIdentifiers();
> > >
> > > I will qualify absence of any identity semantics from SDO a major
> > > drawback. Especially, if it comes to any persistence operation on
> > > SDO DataObject/DataGraph. Hopefully some of the SDO spec writers
> > > would notice this omission and add it to future spec version.
> > >
> > > After a quick pick in current DAS implementation, it appeared that
> > > 'primary key' identification is based on existing database column
> > > name
> >
> > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to learn
> > > how DAS is handling identity issue.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > > That is a good decision. Wrapping should always provide access to
> > > what
> >
> > > is being wrapped.
> > >
> > > > downcasting to the EMF implementation class
> > >
> > > Thanks for this info. I will do this for now. But I heed your
> > > advice
>
> > > and have already a scheme in place that programs against *only*
> > > commonj.sdo API but can access underlying implementaion, if
> > > available,
> >
> > > without any compile-time binding.
> > > Slightly costly -- but works for, say, extracting package name
> > > from Types.
> > >
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > They can't be distinguished in the current version of SDO
> > > metadata, you need to look at the original XSD. The next version
> > > of SDO (SDO
> > > 3) is planning to provide an api for accessing extended XSD
> > > metadata. In Tuscany, you can currently determine this by
> > > downcasting to the EMF implementation class, although we don't
> recommend people do that:
> > >
> > > System.out.println(" Property isID: " +
> > > ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID()));
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03 AM:
> > >
> > > >
> > > > Hi,
> > > >
> > > > A newbie question:
> > > > How does two Property: one defined as xsd:string and other as
> > > > xsd:ID can be distiguished?
> > > >
> > > > Assume:
> > > > 1. we have a simple XML schema defining a Person SDO Type with
> > > > two properties as follows:
> > > > <xsd:complexType name="Person">
> > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > </xsd:complexType>
> > > >
> > > > 2. TypeHelper.INSTANCE.define()
> > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > firstName)
> > >
> > > > and p2 (for id)
> > > >
> > > > 3. both p1.getType().getInstanceClass() and
> > > > p2.getType().getInstanceClass() return java.lang.String
> > > > both p1.getType().isDataType() and p2.getType().isDataType()
> > > > return true
> > > >
> > > > The question is, what can be done to identify p2 as a property
> > > > that were defined as xsd:ID?
> > > >
> > > >
> > > > Thanks for your help --
> > > >
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
Re: Persistence of Service Data Objects using OpenJPA
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Pinaki,
I think your project has a lot of potential. Another related aspect is
that there is interest in the SDO specification charter to discuss the
possibility of converging/supporting JAXB with static SDO in version 3.
JAXB2, as you may know, has a similar objective to support standard POJOs.
If that happens, then I see even more synergy with your approach. At
Tuscany, we'd also be very interested in the bytecode generation that you
mentioned you've prototyped in Fluid. Tuscany has done a little bit of
sandbox prototyping in that area as well, but nobody has had enough time
to really pursue it.
Given this work, I think you should consider getting involved with the DAS
specification effort, if you haven't already.
Frank.
"Pinaki Poddar" <pp...@bea.com>
07/27/2007 12:32 PM
Please respond to
tuscany-dev@ws.apache.org
To
<tu...@ws.apache.org>
cc
<de...@openjpa.apache.org>
Subject
Persistence of Service Data Objects using OpenJPA
Hi Frank,
Thank you for your interest. Before I answer the specific questions
let me say few words to explain why Fluid is attempted at first place.
A) there is a natural synergy between SDO model and the POJO model
where JPA excels.
B) Object Persistence (be it strongly-typed POJO or loosely-typed
SDO) is complex problem by itself. Throw in quirk of multiple database
vendors -- and one really got a hard problem in hand. OpenJPA,
Hibernate, TopLink had worked over many years to solve this problem to a
reasonable degree. SDO persistence should leverage that knowledge/effort
instead of reinventing a costly wheel.
1) Yes -- you're right. The views expressed in
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29 is in agreement with what promoted me to start the lab
(actually I checked this page while researching and mentioned in in my
blog). According to this wiki page: "Work on the specification of a JPA
data access service by the OSOA collaboration is envisaged sometime in
the future but has not started yet."
So Fluid can be considered as a prototype/exploration of similar
ideas.
2) Yes, I am aware of SDO's generation of Java and I have played with
org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to
write yet another code generator for Fluid because
a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type
information defined by XSDHelper.define().
The annotations in the class will be made optional as we proceed --
because JPA allows a separate mapping file
Orm.xml thereby retaining POJO-ness of the persistent domain classes.
b) The generated Java classes is "domain-ready" i.e. they are
self-consistent and independent. Proof: they can
be compiled without any other package other that java.util.*. Adding
annotation, however, makes them compile-dependent on jpa.jar, but that
dependency will be made optional as mapping information can be
externalized in orm.xml.
C) as far as SDO metamodel to Java metamodel mapping goes, it is
essentially isomorphic (at least for this prototype).
SDO2POJO does not introduce any extra artifact (see below). I have not
played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to
make a fair judgement -- but most probably it is generating Java classes
which has more dependency on framework classes in terms of
(inheriting/implementing) as well as package imports.
d) One mapping element is introduced in SDO-Java conversion process.
It is about "Container" SDO Types. I describe the details in Fluid
website. The reason for defining a Container Type abstraction is better
alignment for mapping to relational database (save extra joins and allow
navigational query across multi-cardinality relation paths).
3) Besides the source code generation route, another possibilities is
dynamic Java bytecode generation for SDO Types. Fluid prototyped that
approach too.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 10:39 AM
To: tuscany-dev@ws.apache.org
Subject: RE: How does xsd:ID property type is distinguished from
xsd:string
Hi Pinaki,
This looks very cool, especially that you've got a working prototype! I
have a couple of questions.
1) This seems to overlap with the DAS plan described here:
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29
I'm not very familiar with the DAS work myself, but there seems to be
some overlap with your work.
2) I'm also wondering if you were aware that SDO also defines a mapping
to static Java interfaces/classes. See section 5 of the SDO spec:
http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p
df?version=1
Does your SDO2POJOGenerator conform to that mapping? Have you tried the
Tuscany static SDO generator
(org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
relashionship?
Frank.
"Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> Hello,
> I have been asking newbie questions to this forum. And people have
> been very helpful.
>
> Those newbie questions were for a Apache Lab project named Fluid --
> to explore possibilities of SDO persistence using JPA API.
>
> With all your help, I could put together an initial proptotype that
> creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA
> for SDO and JPA implementation respectively.
>
> Further details of this project (with user documentation) can be
> found at
>
> http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> Your comments/suggestions are most welcome --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Tuesday, July 24, 2007 4:59 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> EAttribute.isID() will only be true if the type is xsd:ID.
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
>
> > Hi Frank,
> > > Database IDs (e.g., primary and foreign keys) are more related
> > to
>
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Thanks for telling me this.
> >
> > Now is ((property.getType().isDataType()) &&
> > ((EAttribute)property).isID())) == true for a property p that is
> > declared as xsd:key or xsd:keyref?
> >
> > Or broadly, what is the semantics of Eattribute.isID()?
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 3:01 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > Identity support is also in the SDO 3 charter: Support for a concept
> > of identity in SDO, and its relationship to other technologies.
> >
> > Database IDs (e.g., primary and foreign keys) are more related to
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> >
> > > Hi Frank,
> > > Thanks.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > >
> > > That is good news. However, identity mechanics should appear
> > > more distinctly on API surface e.g.
> > > boolean Proprty.isIdentifier();
> > > List<Property> Type.getIdentifiers();
> > >
> > > I will qualify absence of any identity semantics from SDO a major
> > > drawback. Especially, if it comes to any persistence operation on
> > > SDO DataObject/DataGraph. Hopefully some of the SDO spec writers
> > > would notice this omission and add it to future spec version.
> > >
> > > After a quick pick in current DAS implementation, it appeared that
> > > 'primary key' identification is based on existing database column
> > > name
> >
> > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to learn
> > > how DAS is handling identity issue.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > > That is a good decision. Wrapping should always provide access to
> > > what
> >
> > > is being wrapped.
> > >
> > > > downcasting to the EMF implementation class
> > >
> > > Thanks for this info. I will do this for now. But I heed your
> > > advice
>
> > > and have already a scheme in place that programs against *only*
> > > commonj.sdo API but can access underlying implementaion, if
> > > available,
> >
> > > without any compile-time binding.
> > > Slightly costly -- but works for, say, extracting package name
> > > from Types.
> > >
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > They can't be distinguished in the current version of SDO
> > > metadata, you need to look at the original XSD. The next version
> > > of SDO (SDO
> > > 3) is planning to provide an api for accessing extended XSD
> > > metadata. In Tuscany, you can currently determine this by
> > > downcasting to the EMF implementation class, although we don't
> recommend people do that:
> > >
> > > System.out.println(" Property isID: " +
> > > ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID()));
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03 AM:
> > >
> > > >
> > > > Hi,
> > > >
> > > > A newbie question:
> > > > How does two Property: one defined as xsd:string and other as
> > > > xsd:ID can be distiguished?
> > > >
> > > > Assume:
> > > > 1. we have a simple XML schema defining a Person SDO Type with
> > > > two properties as follows:
> > > > <xsd:complexType name="Person">
> > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > </xsd:complexType>
> > > >
> > > > 2. TypeHelper.INSTANCE.define()
> > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > firstName)
> > >
> > > > and p2 (for id)
> > > >
> > > > 3. both p1.getType().getInstanceClass() and
> > > > p2.getType().getInstanceClass() return java.lang.String
> > > > both p1.getType().isDataType() and p2.getType().isDataType()
> > > > return true
> > > >
> > > > The question is, what can be done to identify p2 as a property
> > > > that were defined as xsd:ID?
> > > >
> > > >
> > > > Thanks for your help --
> > > >
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Persistence of Service Data Objects using OpenJPA
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Pinaki,
I think your project has a lot of potential. Another related aspect is
that there is interest in the SDO specification charter to discuss the
possibility of converging/supporting JAXB with static SDO in version 3.
JAXB2, as you may know, has a similar objective to support standard POJOs.
If that happens, then I see even more synergy with your approach. At
Tuscany, we'd also be very interested in the bytecode generation that you
mentioned you've prototyped in Fluid. Tuscany has done a little bit of
sandbox prototyping in that area as well, but nobody has had enough time
to really pursue it.
Given this work, I think you should consider getting involved with the DAS
specification effort, if you haven't already.
Frank.
"Pinaki Poddar" <pp...@bea.com>
07/27/2007 12:32 PM
Please respond to
tuscany-dev@ws.apache.org
To
<tu...@ws.apache.org>
cc
<de...@openjpa.apache.org>
Subject
Persistence of Service Data Objects using OpenJPA
Hi Frank,
Thank you for your interest. Before I answer the specific questions
let me say few words to explain why Fluid is attempted at first place.
A) there is a natural synergy between SDO model and the POJO model
where JPA excels.
B) Object Persistence (be it strongly-typed POJO or loosely-typed
SDO) is complex problem by itself. Throw in quirk of multiple database
vendors -- and one really got a hard problem in hand. OpenJPA,
Hibernate, TopLink had worked over many years to solve this problem to a
reasonable degree. SDO persistence should leverage that knowledge/effort
instead of reinventing a costly wheel.
1) Yes -- you're right. The views expressed in
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29 is in agreement with what promoted me to start the lab
(actually I checked this page while researching and mentioned in in my
blog). According to this wiki page: "Work on the specification of a JPA
data access service by the OSOA collaboration is envisaged sometime in
the future but has not started yet."
So Fluid can be considered as a prototype/exploration of similar
ideas.
2) Yes, I am aware of SDO's generation of Java and I have played with
org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to
write yet another code generator for Fluid because
a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type
information defined by XSDHelper.define().
The annotations in the class will be made optional as we proceed --
because JPA allows a separate mapping file
Orm.xml thereby retaining POJO-ness of the persistent domain classes.
b) The generated Java classes is "domain-ready" i.e. they are
self-consistent and independent. Proof: they can
be compiled without any other package other that java.util.*. Adding
annotation, however, makes them compile-dependent on jpa.jar, but that
dependency will be made optional as mapping information can be
externalized in orm.xml.
C) as far as SDO metamodel to Java metamodel mapping goes, it is
essentially isomorphic (at least for this prototype).
SDO2POJO does not introduce any extra artifact (see below). I have not
played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to
make a fair judgement -- but most probably it is generating Java classes
which has more dependency on framework classes in terms of
(inheriting/implementing) as well as package imports.
d) One mapping element is introduced in SDO-Java conversion process.
It is about "Container" SDO Types. I describe the details in Fluid
website. The reason for defining a Container Type abstraction is better
alignment for mapping to relational database (save extra joins and allow
navigational query across multi-cardinality relation paths).
3) Besides the source code generation route, another possibilities is
dynamic Java bytecode generation for SDO Types. Fluid prototyped that
approach too.
Regards --
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Friday, July 27, 2007 10:39 AM
To: tuscany-dev@ws.apache.org
Subject: RE: How does xsd:ID property type is distinguished from
xsd:string
Hi Pinaki,
This looks very cool, especially that you've got a working prototype! I
have a couple of questions.
1) This seems to overlap with the DAS plan described here:
http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%
28JPA%29
I'm not very familiar with the DAS work myself, but there seems to be
some overlap with your work.
2) I'm also wondering if you were aware that SDO also defines a mapping
to static Java interfaces/classes. See section 5 of the SDO spec:
http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p
df?version=1
Does your SDO2POJOGenerator conform to that mapping? Have you tried the
Tuscany static SDO generator
(org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any
relashionship?
Frank.
"Pinaki Poddar" <pp...@bea.com> wrote on 07/26/2007 10:41:27 PM:
> Hello,
> I have been asking newbie questions to this forum. And people have
> been very helpful.
>
> Those newbie questions were for a Apache Lab project named Fluid --
> to explore possibilities of SDO persistence using JPA API.
>
> With all your help, I could put together an initial proptotype that
> creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA
> for SDO and JPA implementation respectively.
>
> Further details of this project (with user documentation) can be
> found at
>
> http://people.apache.org/~ppoddar/fluid/site/welcome.html
>
> Your comments/suggestions are most welcome --
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Tuesday, July 24, 2007 4:59 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: How does xsd:ID property type is distinguished from
> xsd:string
>
> EAttribute.isID() will only be true if the type is xsd:ID.
>
> Frank.
>
> "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 05:31:09 PM:
>
> > Hi Frank,
> > > Database IDs (e.g., primary and foreign keys) are more related
> > to
>
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Thanks for telling me this.
> >
> > Now is ((property.getType().isDataType()) &&
> > ((EAttribute)property).isID())) == true for a property p that is
> > declared as xsd:key or xsd:keyref?
> >
> > Or broadly, what is the semantics of Eattribute.isID()?
> >
> >
> > Pinaki Poddar
> > 972.834.2865
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: Tuesday, July 24, 2007 3:01 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: How does xsd:ID property type is distinguished from
> > xsd:string
> >
> > Hi Pinaki,
> >
> > Identity support is also in the SDO 3 charter: Support for a concept
> > of identity in SDO, and its relationship to other technologies.
> >
> > Database IDs (e.g., primary and foreign keys) are more related to
> > xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning
> > to address all of them :-)
> >
> > Frank.
> >
> > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 11:02:21 AM:
> >
> > > Hi Frank,
> > > Thanks.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > >
> > > That is good news. However, identity mechanics should appear
> > > more distinctly on API surface e.g.
> > > boolean Proprty.isIdentifier();
> > > List<Property> Type.getIdentifiers();
> > >
> > > I will qualify absence of any identity semantics from SDO a major
> > > drawback. Especially, if it comes to any persistence operation on
> > > SDO DataObject/DataGraph. Hopefully some of the SDO spec writers
> > > would notice this omission and add it to future spec version.
> > >
> > > After a quick pick in current DAS implementation, it appeared that
> > > 'primary key' identification is based on existing database column
> > > name
> >
> > > "ID" (yes, hardcoded) -- but I may be wrong and am ready to learn
> > > how DAS is handling identity issue.
> > >
> > > > SDO (SDO 3) is planning to provide an api for accessing extended
> > > > XSD
> > > metadata
> > > That is a good decision. Wrapping should always provide access to
> > > what
> >
> > > is being wrapped.
> > >
> > > > downcasting to the EMF implementation class
> > >
> > > Thanks for this info. I will do this for now. But I heed your
> > > advice
>
> > > and have already a scheme in place that programs against *only*
> > > commonj.sdo API but can access underlying implementaion, if
> > > available,
> >
> > > without any compile-time binding.
> > > Slightly costly -- but works for, say, extracting package name
> > > from Types.
> > >
> > >
> > >
> > > Pinaki Poddar
> > > 972.834.2865
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: Tuesday, July 24, 2007 9:16 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: How does xsd:ID property type is distinguished from
> > > xsd:string
> > >
> > > Hi Pinaki,
> > >
> > > They can't be distinguished in the current version of SDO
> > > metadata, you need to look at the original XSD. The next version
> > > of SDO (SDO
> > > 3) is planning to provide an api for accessing extended XSD
> > > metadata. In Tuscany, you can currently determine this by
> > > downcasting to the EMF implementation class, although we don't
> recommend people do that:
> > >
> > > System.out.println(" Property isID: " +
> > > ((property.getType().isDataType()) &&
> > > ((EAttribute)property).isID()));
> > >
> > > Frank.
> > >
> > > "Pinaki Poddar" <pp...@bea.com> wrote on 07/24/2007 01:00:03 AM:
> > >
> > > >
> > > > Hi,
> > > >
> > > > A newbie question:
> > > > How does two Property: one defined as xsd:string and other as
> > > > xsd:ID can be distiguished?
> > > >
> > > > Assume:
> > > > 1. we have a simple XML schema defining a Person SDO Type with
> > > > two properties as follows:
> > > > <xsd:complexType name="Person">
> > > > <xsd:attribute name="firstName" type="xsd:string"/>
> > > > <xsd:attribute name="id" type="xsd:ID"/>
> > > > </xsd:complexType>
> > > >
> > > > 2. TypeHelper.INSTANCE.define()
> > > > defines SDO Type with two commonj.sdo.Property, p1 (for
> > > > firstName)
> > >
> > > > and p2 (for id)
> > > >
> > > > 3. both p1.getType().getInstanceClass() and
> > > > p2.getType().getInstanceClass() return java.lang.String
> > > > both p1.getType().isDataType() and p2.getType().isDataType()
> > > > return true
> > > >
> > > > The question is, what can be done to identify p2 as a property
> > > > that were defined as xsd:ID?
> > > >
> > > >
> > > > Thanks for your help --
> > > >
> > > >
> > > >
> > > >
> > > > Pinaki Poddar
> > > > 972.834.2865
> > > >
> > > > 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.
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > 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.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org