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]
