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]
