Hi Ron, You asked me about this about a month ago, and here was my answer:
> SDO 2.1 has added a new method for this, Property.isNullable(). > Unfortunately we haven't implemented in yet in Tuscany (it > currently throws UnsupportedOperationException if you > call it). > The implementation plan is to add an EAnnotation on > EStructuralFeatures created in SDOXSDEcoreBuilder, to store the > nillable value, and then use that EAnnotation to implement the > new isNullable() method. > It's not on our high priority list but If you'd like to do it > and provide a patch, that would be most welcome. > Thanks, > Frank. So, if you'd like to help, we can get this finished very soon :-) Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 03/06/2007 01:38:35 PM: > Hi Frank, > > Thanks for clearing this issue up for me. I appreciate it. > > Now that Tuscany has implemented this new SDO 2.1 design, it seems > pretty important to support Property.isNullable(). Is there a JIRA # > for this issue? Is it planned for M3? For us, the SDO 2.1 behavior > may prove problematic without it. > > Thanks again, > > - Ron > > ----- Original Message ---- > From: Frank Budinsky <[EMAIL PROTECTED]> > To: tuscany-user@ws.apache.org > Sent: Tuesday, March 6, 2007 12:14:38 PM > Subject: Re: SDO - XML Schema element with default attribute behaves > as if nillable="true" > > > Hi Ron, > > The serialization behavior is based on isSet() behavior, so you should be > concerned abou it :-) A property is serialized only if isSet() is true. > The SDO 2.1 design is that isSet() returns true if the property has been > set (period). Unlike EMF, it has nothing to do with the default value. So > if you set to null (valid or not), isSet will return true and you'll get > an element serialized and xsi.nil will be used to represent a null value. > We've already implemented this behavior in Tuscany. > > Frank. > > P.S. Another new feature in SDO 2.1 is Property.isNullable() to determine > whether or not null is a valid value for a property. We haven't > implemented this in Tuscany yet. > > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 03/06/2007 11:56:22 AM: > > > Hi Frank, > > > > Thanks for the quick reply. > > > > I'm less concerned about the actual isSet() behavior and more > > concerned with 1. serialization and 2. the behavior of unset() vs. > > set(null). In M2, when nillable = "false", unset() and set(null) > > behave similarly in that both adhere to the same serialization > > semantics. OTOH, when nillable = "true", unset serializes as an > > absent element whereas set(null) serializes w/xsi:nil="true". The > > presence of a default attribute triggers the nillable = "true" > > serialization semantics. How is this supposed to work in SDO 2.1? > > How does it work currently in the Tuscany SVN head? How will it work > > in Tuscany M3? > > > > Thanks in advance. > > > > - Ron > > > > ----- Original Message ---- > > From: Frank Budinsky <[EMAIL PROTECTED]> > > To: tuscany-user@ws.apache.org > > Sent: Tuesday, March 6, 2007 11:39:23 AM > > Subject: Re: SDO - XML Schema element with default attribute behaves > > as if nillable="true" > > > > > > 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] > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- > 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]
