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]
