[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] Oracle Proposal: SDO 99 - ISSUE 99: Error in allocatingSDO Type for elements with nillable=true
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] Good point Blaise. In retrospect, using a
primitive base type is a bad idea, period.
One
other thing with this part: Proposal 2 - Set
the default default value for properties corresponding to extended primitive
types to the base primitive types default value
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: ·
The user would
see a different super type on their extended simple type ·
Null would become
a valid value on that property, but user would still have to explicitly set a
null value. Advantages ·
There is only one
SDO type that corresponds to an extended simple type in an XML schema: ·
Useful if you
want to regenerate the XML Schema from the types ·
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
implement (logic is restricted to type definition, and only when an extended
simple type is encountered). ·
Simpler to write
the description in the specification -Blaise |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]