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 > [email protected] > > > To > <[email protected]> > 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: [email protected] > 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: [email protected] > > 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: [email protected] > > > 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: [email protected] > > > > 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]
