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.pdf?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]
