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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> > 07/27/2007 12:32 PM
> > Please respond to
> > tuscany-dev@ws.apache.org
> >
> >
> > To
> > <tuscany-dev@ws.apache.org>
> > cc
> > <[EMAIL PROTECTED]>
> > 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:[EMAIL PROTECTED]
> > 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > > 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > > > 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" <[EMAIL PROTECTED]> 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:
> > > > > > [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> > > > > > [EMAIL PROTECTED]
> > > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > > 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: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > > 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: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > > 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
