What specifically do you mean by: > makes the SDO runtime treat quantity as if the element also had the attribute, nillable="true".
If you're referring to the behavior of isSet() after you call set(null), then this is a feature inherited from EMF. If a property was a default value, the property becomes EMF-unsettable, so isSet() will always return true after set(). The fact that null is not a legal value (since the type is not nillable) is a validation issue. Note that in SDO 2.1, all features will behave this way - even the ones without default value. There was a clarification in semantics of isSet in the 2.1 SDO spec, so this EMF-specific behavior will no longer apply. Frank Ron Gavlin <[EMAIL PROTECTED]> wrote on 03/06/2007 11:13:51 AM: > Greetings, > > I am using the M2 SDO release. Assume I have registered a schema > that includes the following snippet: > > ... > <xs:element name="item" maxOccurs="unbounded"> > <xs:complexType> > <xs:sequence> > <xs:element name="title" type="xs:string"/> > <xs:element name="note" type="xs:string" minOccurs="0"/> > <xs:element name="quantity" type="xs:nonNegativeInteger" > minoccurs="0" default="0" /> > <xs:element name="price" type="xs:decimal"/> > </xs:sequence> > </xs:complexType> > </xs:element> > ... > > It appears the presence of a default attribute on the "quantity" > element makes the SDO runtime treat quantity as if the element also > had the attribute, nillable="true". Is this a bug? If so, I'll be > happy to register a JIRA issue. Let me know. > > - Ron > > --------------------------------------------------------------------- > 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]
