openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Budinsky <fra...@ca.ibm.com>
Subject Re: Persistence of Service Data Objects using OpenJPA
Date Fri, 27 Jul 2007 19:59:00 GMT
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" <ppoddar@bea.com> 
07/27/2007 12:32 PM
Please respond to
tuscany-dev@ws.apache.org


To
<tuscany-dev@ws.apache.org>
cc
<dev@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" <ppoddar@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" <ppoddar@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" <ppoddar@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" <ppoddar@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




Mime
View raw message