If we are going to allow a property with a type in which the instance
class is int.class return null, then we should be discussing the
removal of the types in defined in the Java spec (table 6.1.2), as
they are no longer needed.
if(myProperty.getType().getInstanceClass() == int.class) {
int result = myDataObject.get(myProperty, Integer.class); // This
may fail in 3.0
}
-Blaise
Frank Budinsky wrote:
OF982C3305.24E906E3-ON85257785.004D85B0-85257785.0050E399@ca.ibm.com"
type="cite">
Hi Ron,
First, for the second sentence I think it would need to be:
A (Java) Implementation of
SDO MUST return NULL as the property value for nillable properties
having the xsi:nil=true attribute (and no other attributes), regardless of whether the instanceClass of the SDO type
corresponding to the type
used in the schema normally supports null values.
Even then, I wonder what this is really needed for. Why is it so
important to dwell on the type/instanceClass? I think the spec is
absolutely clear when a null value can be expected, and it has nothing
to do with the type and whether or not the type is assignable from
Object.class.
Setting the value of a property
to null may or may not be allowed for a given property.
For example, a property that
does not map to a nillable XML element or that maps to a
non-nullable RDB column, cannot
be set to null. A property that can be set to null is
called a nullable property.
Calling get() on a property
that is not nullable may still return a null value, if the default
value of the property is null
and it is currently unset. Calling set(null) on a non-nullable
property will produce
implementation dependent results. It may throw an exception or,
alternatively, it may cause the
property to become unset.
From this very clear text, I'd say this is the test for expectedNull:
Boolean expectNull =
pMstNillable.isNullable() || pMstNillable.getDefault() == null);
Notice that it has nothing to do with pMstNillable.getType(). In fact,
the test that you provided:
Boolean expectNull =
pMstNillable.getType().getInstanceClass().isAssignableFrom(Object.class);
is actually incorrect, according to the spec. It would incorrectly
return true for a property that is not nullable and its default value
is something other than null.
Your suggestion to change the spec to this;
Property name=[NAME]
type=[TYPE]
nullable=true
would break implementations that have two SDO types corresponding to
the simple primitive types (e.g., XXX and XXXObject), and switch to the
Object version in the nillable case. Personally, I think that's a bad
legacy approach which was devised before we had the concept of
Nullable, but changing it would be a breaking spec change.
Maybe the answer is simply to remove the (what I consider to be)
confusing/ambiguous text but otherwise leave the table alone --- i.e.,
simply show that nillable maps to nullable:
Property name=[NAME]
nullable=true
Thanks,
Frank.
"Barack, Ron"
---08/20/2010 06:51:13 AM---Hi Frank, I think you understand what I was
proposing.
Hi Frank,
I think you understand what I
was proposing.
Let’s look at the text as it
currently stands
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.
I think we agree that the second
sentence means:
A (Java) Implementation of
SDO MUST return NULL as the property value for nillable properties
having the xsi:nil=true attribute, regardless of whether the type used
in the schema normally supports null values.
The disagreement is about the
first sentence. I think you are correct is assuming “Java Type” should
be “SDO Type”. I don’t believe that this mistake is so big that we can
ignore the sentence entirely. And the example makes it perfectly clear
that that the type of the property should have an instanceClass of
IntObject and not int. Also, in the area above the text, where the
translation of the XML is given, the Property’s definition does not
contain a “type=[TYPE] like the other boxes do. The text is clearly
trying to explain how the property’s type should be calculated. Given
that, I would consider an implementation that says
pMstNillable.getType()==MySimpleType to be broken *according to 2.1.1*. At least in my opinion. But let’s
consider how things should be in 3.0
First of all, I think the
behavior you want do define shouldn’t be defined in the chapter on the
SDO-XSD mapping, but rather in the section (4.5.5) on Nullable
properties…the user has no standard way of seeing if xs:nillable is
true in the schema, but can easily check Property.isNullable(). The
main use-case (that I can think of) where this would be relevant is
where the user is inspecting the metadata, to determine if a null value
is possible. Currently, this determination can be made based on
Property.getType().getInstanceClass() alone, eg,
Boolean expectNull =
pMstNillable.getType().getInstanceClass().isAssignableFrom(Object.class);
I think you want to change this
so that the user needs to check not only the instanceClass, but also
Propery.isNullable():
Boolean expectNull =
pMstNillable.getType().getInstanceClass().isAssignableFrom(Object.class)
||
pMstNillable.isNullable();
I think this makes both Tuscany
and your new implementation legal. I also think this is technically OK,
even sensible, but I’m worried that it is this a breaking change. If
every agrees that this should be the behavior, then I don’t think it
will be hard to come up with appropriate wording in 4.5.5, and in the
corresponding Java section. Then, the XSD-SDO mapping that we started
with becomes simply
Property name=[NAME]
type=[TYPE]
nullable=true
without any text at all!
Have I correctly summarized the
behavior you want to define? Like I said before, I need to think about
whether this is a breaking change or not. Blaise, what do you think?
Have a nice weekend,
Ron
Von: Frank
Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 20. August 2010 00:03
An: sdo@lists.oasis-open.org
Betreff: RE: AW: AW: [sdo] AW: ISSUE 99:
Error in allocating SDO Type for elements with nillable=true
Hi Ron,
Sorry, I did mean for my previous reply to go to the list.
In Tuscany we created an "Object" version of every user defined simple
type which had a base class with a primitive instanceClass (just in
case it's ever used with a nillable property). We would generate two
SDO types from the XSD type: MySimpleType (instanceClass int) and
MySimpleTypeObject (instanceClass Integer). Notice that's exactly the
same pattern that was used with the built-in types (e.g., Int and
IntObject). This is no coincidence, since a predecessor version of
Tuscany was the primary implementation with which the SDO 1
specification was defined.
I think something like this is essentially what you're proposing (only
not naming the Object version XXXObject, but rather making the Object
types anonymous.
In another newer SDO implementation, we've handled this the way I've
proposed below, simply by using the type itself, but allowing null to
be returned as an "extended value", because the property is nillable.
Because of the ambiguity in the spec, we concluded that this is really
not noncompliant with the spec. IMO, the spec is only saying that the
returned value's Java Type must be an Object type. Since
get(primitiveTypeProperty) always returns the corresponding Object type
anyway (e.g., Integer, since it can't return int) we're OK to also
return null. Like I said in my earlier reply, the distinction between
primitive and Object values really only comes into play in static SDO.
This approach seems to be simpler than the Tuscany approach and works
quite reasonably as far as I can tell. Can you explain an example of
where this approach would really cause a problem?
That said, your point that I am saying the spec is currently
ambiguous/broken but I'd like to leave it that way, is a good one. I'm
certainly being a little irresponsible. However, if we do fix this in a
way that will make the approach I've described noncompliant, I'd want
to be convinced that there is really something wrong with our approach
(i.e., it is really broken/bad) because if we change it, we would be in
a position where our implementation will not be backward compatible if
we want to be SDO 3 compliant. I rather not be in a position where
backwards compatibility becomes an obstacle for moving to our
implementation to SDO 3, if we can avoid it.
Thanks,
Frank.
"Barack, Ron" ---08/19/2010 05:09:26 PM---Hi Frank, You sent
this to me, did you mean to send it to the SDO list?
From: |
"Barack, Ron" <ron.barack@sap.com> |
To: |
Frank Budinsky/Toronto/IBM@IBMCA |
Date: |
08/19/2010 05:09 PM |
Subject: |
RE: AW: AW: [sdo] AW: ISSUE 99: Error in allocating SDO Type for
elements with nillable=true |
Hi Frank,
You sent this to me, did you mean to send it to the SDO list?
An old fashioned argument, just like the good old 2.1 days!
My opinion is that the spec is clear on the point that
pMstNillable.getType().getInstanceClass() is (MUST BE) the
instanceClass of IntObject. And, today at least, I think that’s pretty
reasonable. Assuming I’m the one trying to get the spec to 2119
compliant, I’d probably have to put in a compliance point there. That
doesn’t mean I won’t accept a resolution that loosens up the definition
of compliant behavior, it just means that if we defer this, and you are
unhappy with the defined behavior, we will just wind up discussing the
same issue later. Let’s get it over with now. You even point out that
you don’t know what the statement means, but then you go on to say you
think the statement should be left as it is. Personally, I don’t even
know if the statement belongs in Core or in Java. Let’s work out some
wording here that everyone can be happy with.
I agree with Blaise that we are breaking SDO if we allow a property
with instanceClass int, or deriving from Integer (as opposed to
IntObject) to have null values. I think this use case is important, but
not important enough to warrant such a fundament change to the
relationship between data and metadata. Therefore, it seems pretty
clear that pMstNillable.getType() cannot be MySimpleType. I think the
spec should say so. We can maybe then get out of the issue about saying
anything else about the type, leaving implementations free to use
IntObject, an anonymous type, or anything else. I think the xmlType of
the property should be the URI of MySimpleType.
In my reading of the spec, this is just adding the stuff about the
XMLType.
Would you go with me so far?
Ron
From: Frank Budinsky [mailto:frankb@ca.ibm.com]
Sent: Donnerstag, 19. August
2010 16:14
To: Barack, Ron
Subject: Re: AW: AW: [sdo] AW:
ISSUE 99: Error in allocating SDO Type for elements with nillable=true
Hi Ron,
The 2.1.1 spec does not say this:
"the property MUST be created with IntObject"
Mapping a property to IntObject instead of Int is simply an example of
how to handle a nillable property of type xsd:int. All the spec really
says about nillable elements is:
If the type of the element has Simple Content without attributes, a
Java Type with an Object instance class is assigned.
I'm not even sure what a "Java Type" with an Object instance class
means. Notice it doesn't say an "SDO Type" with an Object instance
class. So that's the first ambiguous statement.
Let's assume that it really meant to say "SDO Type", then what is
supposed to happen if the specified type, e.g., MySimpleType, doesn't
have an Object instance class? The spec is very clear that unless
sdoj:instanceClass is specified, the instanceClass of a type is the
instanceClass of its base type, so I'd say you're example is an
unsupported (error) case in the spec, since the type being requested
cannot be used with a nillable property, because it's corresponding
Java Type does not have an Object instance class.
On the other hand let's assume that all this means is that somehow, an
implementation should figure out a way to arrange for the "Java Type"
being used for the property, to be one with an Object instance class.
With that reading of the ambiguous statement, all 3 of the our
approaches (yours, Blaise's, and mine) would work.
Since it's been this way since SDO 1, I don't see any urgent need to
try to fix it now. I'm happy to continue to leave the handling of this
as implementation dependent.
Thanks,
Frank
"Barack, Ron" ---08/19/2010 09:11:15 AM---Hi Frank, In this
case, deferring doesn't mean leaving things open, it means to keep the
2.1.1 behav
Hi Frank,
In this case, deferring doesn’t mean leaving things open, it means to
keep the 2.1.1 behavior, i.e., the property MUST be created with
IntObject, get(mstProperty) MUST return an Integer, never an int. And
when you generate XSD from the MyComplexType, the <element> MUST
have type=”xs:Integer”. Are you OK with this behavior, or can we do
better? I agree we should change as little as possible, but I think we
can at least say, starting with the 2.1.1 baseline, that the property
should have the xmlType of MySimpleType, so that at least we do a
better job of round tripping without breaking anything.
It seems a short step to create an anonymous type, which I think would
really be a fix for the issue.
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Donnerstag, 19.
August 2010 14:38
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] AW:
ISSUE 99: Error in allocating SDO Type for elements with nillable=true
Hi Guys,
I don't think this issue is urgent and, from this note chain, we can
conclude that this is not an issue for which we are close to consensus.
I think we should defer it.
Thanks,
Frank.
"Barack, Ron" ---08/19/2010 06:50:09 AM---Hi Blaise, Frank,
Three voices, three opinions is about what I expected. I think I'll go
ahead and
Hi Blaise, Frank,
Three voices, three opinions is about what I expected. I think I’ll go
ahead and add a fourth. First, some comments on your ideas:
@Blaise: I think the solution of making the instanceClass of all
derived types Object types is certainly technically sound. My guess is
that we are all storing values in Objects anyway. But I’m concerned
about backwards compatibility. And I don’t think this is what users
will expect.
@Frank: I think the difference in our perspectives boils down to the
fact that I think it’s a problem for the instanceClass of a property to
be different from the instanceClass of that property’s type. Property’s
don’t have instanceClasses, Type’s do. It’s a pretty big change to
suggest otherwise. Even if the static SDO issue falls away because we
don’t generate the interfaces ourselves, there are certainly may other
places where we assume that a property’s instanceClass is exactly what
you’d expect from inspecting the type.
So, now on to another idea:
If we assume that for most applications, the correct representation of
the DATA is more important than correct representation of the METADATA,
then it is more important that get(pMstNillable) return null than it is
that pMstNillable==pMst. If we want everything to be consistent , then
that means that pMstNillable has to be or derive from IntObject. In
order to round trip our metadata, we can add in that the xmlType of the
property should be MySimpleType.
The spec currently says that pMstNillable.getType==MySimpleType. I
think the only real problem with this is that we lose the facets or
other metadata that is associated with the type. I think one possible
solution to this would be to define an anonymous type that copies
everything from MySimpleType other than its name and instanceClass.
What’s good about this solution is that the nill values are represented
AND the property’s values are consistent with the property’s metadata.
And o it does not lose any metadata, as long as the user gets the type
from property.getType and does not try to look it up over its name
(which is already broken in 2.1.1).
Best Regards,
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Mittwoch, 18. August
2010 22:54
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] AW: ISSUE
99: Error in allocating SDO Type for elements with nillable=true
I think MySimpleType having
instanceClass int.class is fine. We just need to say that the
instanceClass of a nillable property which is of a type that has a Java
primitive instanceClass (e.g., int.class) will effectively be promoted
to the Object version of the type's instanceClass (e.g., Integer.class)
since null is also a valid value for the property. Effectively, this is
just saying that the instnaceClass of a nillable property may not be
exactly the same as the instanceClass of the property's type. Although
the rule to figure it out is trivial, we could add a
Property.getInstanceClass() method that returns it.
The value space of the pMstNillable property is the MySimpleType type's
value space (i.e., MIIN_INTEGER to MAX_INTEGER) :
1. pMst unset
myObject.get(pMst) == 0
2. pMst set to 10
myObject.get(pMst) == 10
3. pMst set to nil
myObject.get(pMst) == 0 (or error since this is invalid data)
The value space of the pMstNillable property is the MySimpleType type's
value space (i.e., MIIN_INTEGER to MAX_INTEGER) plus null (because it's
a valid value for a nullable property).
1. pMstNillable unset
myObject.get(pMstNillable) == 0
2. pMstNillable set to 10
myObject.get(pMstNillabe) == 10
3. pMstNillable set to nil
myObject.get(pMstNillable) == null
Frank.
Blaise Doughan ---08/18/2010 04:11:08 PM---If the instance
class for MySimpleType is *int.class* then I would expect:
myObject.get(Integer.cl
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:
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
|