[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating SDOType for elements with nillable=true
Hi Ron,
Hi Guys, I’m missing something here: is having getInteger(oddProperty) return null breaking change? I mean, you can argue that the default value should be on type rather than property, but that’s really not the issue here. Current code that deals with user-defined simple types deriving from xs:integer will not expect to get nulls. I don’t know why “it makes no sense to force a default value on a restricted type“. It seems rather like you are argueing that SDO is missing the default default value on (user-defined) types. To my mind, the concept is already there, but the proposal hangs together much better if this concept was built out in our metadata. It would be cool to say “odd” as a default value of 1, wherever it is used. Seems a little late to be playing with the metamodel, tho. In any case, removing the second part of the proposal doesn’t do away with the concept of types having a default default value, or the problem that they may or may not fit. It makes the situation worse in that it allows null to be the default default values in cases where we know null does not fit. Do you guys agree that the section on schema-SDO mapping is not the place to handle this? After all, you could get the same conflict through the api, declaring the property with sdo:integer and then the property with nullable. In fact, right now, you could even define a nullable property with type sdo:integer: we don’t say that the property’s types should be automatically adjusted. I would suggest that in the schema sdo table we have a simple mapping, but refer the user to section 5.2.2. In this section, we all have to describe how a conflict between a nullable property and a non-nullable type (we’d have to somehow define this) is handled. And then, in the Java spec, we define which SDO types this affects. Best Regards, Ron Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Donnerstag, 26. August 2010 17:38 An: Blaise Doughan Cc: sdo@lists.oasis-open.org Betreff: Re: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocating SDO Type for elements with nillable=true Good point Blaise. In retrospect, using a primitive base type is a bad idea, period.
If the base type was SDO Int the default value would still be 0 :). -Blaise Frank Budinsky wrote:
Proposal 2 - Set the default default value for properties corresponding to extended primitive types to the base primitive types default value
Hi Blaise, Your proposal is clean and does work nicely, but it has one serious disadvantage IMO. From what I've seen, user defined simple types seem to be rarely (almost never) nillable. The reason, I presume, is because the purpose of the subtype is to specify a restricted subset of the values allows by the type. It seems to be uncommon to combine such a restriction of the value set with an extension of the value set to allow null. If this is the case, your proposal is penalizing all restricted type users (i.e., forcing them to work with Object instead of the simpler primitive type) just to accommodate a very rare use case. Frank. Blaise Doughan ---08/26/2010 10:18:20 AM---Hello All, Below is a more detailed description of the Oracle proposal for SDO 99.
Hello All, Below is a more detailed description of the Oracle proposal for SDO 99. Section 7.4.2 of the Core Spec regarding nillable simple elements "If the type of the element has Simple Content without attributes, a Java Type with an Object instance class is assigned. For example, IntObject instead of Int. In an XML document, xsi:nil="true" corresponds to a null value for this property."
If oddInt extends xsd:int currently
Simple Type with name <simpleType name=[NAME]> corresponds to: Type name=[NAME] Meaning that our "oddInt" type will have the super type of Int. THIS is where I think the spec is wrong. Instead of extending Int, it should extend IntObject since this type may be used by a nillable element.
base="[BASE]" if base is capable or represented null, other wise the base corresponds to the corresponding object type Proposal 2 - Set the default default value for properties corresponding to extended primitive types to the base primitive types default value
With the above proposals the impact on the user should be minimal:
· Null would become a valid value on that property, but user would still have to explicitly set a null value.
· Useful if you want to have an editor or validator associated with that type · Having one type requires less memory than having multiple copies of that type · Simpler to write the description in the specification |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]