If the instance class for MySimpleType is int.class then I
would expect: myObject.get(Integer.class,
pMstNillable) == 0
If the instance class for MySimpleType is java.lang.Integer.class then
I would expect: myObject.get(Integer.class,
pMstNillable) == null
The problem is we don't know what instance class to set on MySimpleType
because we don't know it will be used by a nillable property. We could
I guess in this situation always give these derived simple types the
Object version of the instance class?
-Blaise
Frank Budinsky wrote:
OFCF2EF496.1E12AB10-ON85257783.00696EA8-85257783.006B64CC@ca.ibm.com"
type="cite">
Hi Ron,
Maybe I'm missing something, but the answers to me are straightforward.
Q1: What is the value of
pMstNillable.getType()?
A1-1: pMst.getType(), that is
pMstNillable.getType().getName().equals(“MySimpleType”);
Q2: Assuming “A1-1”, what
should myObject.get(pMstNillable) return?
A2-2: null – this gives the
detail about nil value, but I think users will still be surprised,
since the value is inconsistent with the property’s metadata.
Why do you think this is inconsistent with the property's metadata? The
property is "nillable", so a return value of null seems perfectly
reasonable.
Q3: Assuming “A1-1”, what
should myObject.get(Integer.class, pMstNillable) return?
A3-2: null – this is what users
would expect. It would mean the implementation must remember the
xsi:nill=”true” in addition to the integer value.
Remember what integer value? There is no integer value. The value is
"nil". An instance can only have a value or nil, not both.
The only thing I think is special about nillable properties is that
they need to return the Object version of primitive types in static SDO:
public int getMst() { ... }
public Integer getMst_nillable() { ... }
instead of the primitive instanceClass of the type, which won't allow
null as a return value:
public int getMst_nillable() { ... }
Since the DataObject.get() methods always return Object types, there's
no problem with them.
Thanks,
Frank.
"Barack, Ron"
---08/18/2010 09:33:49 AM---Hi Everyone, Based on yesterday's
discussion, let me offer an example as a basis for discussion. Fo
Hi Everyone,
Based on yesterday’s discussion,
let me offer an example as a basis for discussion. For clarity, I’m
leaving out all namespace stuff
We start with a schema that
defines a simple type:
<xs:simpleType
name=”MySimpleType” base=”xs:integer”>
<xs:minInclusive
value=”5”/>
</xs:simpleType>
Let’s assume the schema defining
this type is read in and that SDO has created the type. Sometime later,
we read in another schema that uses the type in an element property…
I’m imagining it in a second schema, if the use is in the same schema,
we could potentially decide when defining the type that it’s instance
class should be Integer and not “int”, but if the usage is in a second
schema, then clearly we can no longer modify the existing type
definition. So, let’s imagine a second schema
<xs:element name=”MyDoc”
type=”MyComplexType”>
<xs:complexType
name=”MyComplexType”>
<xs:sequence>
<xs:element name=”mst”
type=”MySimpleType”/>
<xs:element
name=”mst_nillable” xs:nillable=”true” type=”MySimpleType”/>
<xs:element name=”i”
type=”xs:integer”/>
<xs:element
name=”i_nillable” xs:nillable=”true” type=”xs:integer”/>
</xs:sequence>
</xs:complexType>
Here’s an instance document:
<MyDoc>
<mst>7</mst>
<mst_nillable
xsi:nil=”true”/>
<i>21</i>
<i_nillable
xsi:nil=”true”/>
</MyDoc>
Let’s imagine some code using
these files:
DataObject myObject =
xmlHelper.load(…).getRootObject();
Type complexType =
myObject.getType();
Property pMst =
complexType.getProperty(“mst”);
Property pMstNillable =
complexType.getProperty(“mst_nillable”);
Property pI =
complexType.getProperty(“i”);
Property pINillable =
complexType.getProperty(“i_nillable”);
So, I guess the first question
is:
Q1: What is the value of
pMstNillable.getType()?
A1-1: pMst.getType(), that is
pMstNillable.getType().getName().equals(“MySimpleType”);
I think this is what users
would expect.
A1-2: sdo:IntObject, that is
pINillable.getType().
This is what the spec currently
says. But of course, we are losing information…in this case, the
restriction. Not to mention that theres a round-tripping problem.
I guess A1-1 is preferable, but
it creates problems when dealing with nils. This brings us to our
second question:
Q2: Assuming “A1-1”, what
should myObject.get(pMstNillable) return?
A2-1: 0 – this would mean
ignoring the nillable attribute.
A2-2: null – this gives the
detail about nil value, but I think users will still be surprised,
since the value is inconsistent with the property’s metadata.
A2-3: A wrapper data object,
and we could add some means of inspecting it for “isNull”… this is the
pattern we use when dealing with dataTypes that need to be handled like
objects.
Q2: Assuming “A1-1”, what
should myObject.get(Integer.class, pMstNillable) return?
A2-1: Integer.valueOf(0) – this
would mean ignoring the nillable attribute.
A2-2: null – this is what users
would expect. It would mean the implementation must remember the
xsi:nill=”true” in addition to the integer value.
BTW, sorry if there are errors
in the schema or java code…this is only meant to be the basis for
discussion, and I think the intent is clear.
My own current thinking is that
the first answers to each question is the best choice. But maybe there
are other solutions.
OK… let the discussion begin!
Ron
_____________________________________________
Von: Barack, Ron
Gesendet: Dienstag, 17. August 2010 16:31
An: sdo@lists.oasis-open.org
Betreff: ISSUE 99: Error in allocating
SDO Type for elements with nillable=true
Hi everyone.
The problem description is here: http://www.osoa.org/jira/browse/SDO-99
In the current WD, the problem is in the table
in section 7.4.2, in the block “Element with nillable”. There are a lot
of editorial issues with this text, for instance, the reference to Java
types does not really belong in the core spec. but more substantively:
the issue boils down to the problem that “xsi:nillable” is on
properties, but “sdo:nullable” is on types. If you have a type that is
defined as being an unboxed primitive value, we can’t simply change the
type’s definition because it’s used in a nillable property. (I hope we
all agree here).
In my opinion there are 4 possibilities.
1. We ignore the xsi:nillable
2. We use a SDO primitive object type
(IntObject), and use the type referenced in the XSD as the XmlType only.
3. We use wrapper objects.
4. We defer the issue
I prefer option 3 and volunteer to write it up,
if we get approval for the approach on today’s call.
Ron
|