[sdo] [SDO-15]: Type determination for Open Content Properties

[Radu Preotiuc-Pietro <radup@bea.com>]

Ron Barack:

There is a similar issue when demarshalling OpenContent attributes.

Here, however, conversion to string is not problematic since the
attribute is already a string in the XML.

For OpenContent elements, xsi:type should be used, as in Omar's
polymorphic property proposal. 


Steve Brodsky:

It seems that xsi:type is sufficient to specify the type in an XML
document, and they type is always known in memory. If there is a further
issue please reopen.


Henning Blohm:

sorry to reopen, but what is supposed to happen in the non-xml case?

given some open DataObject d, and setting

d.set("newprop",new java.util.Date());

should the new open content propery "newprop" be of type
{commonj.sdo}String or rather {commonj.sdo}Date?


Frank Budinsky:

I agree with the original proposal, above, that it should use the same
thing that TypeHelper.getType(Class) returns. It's not completely clear
in the spec, but the tables on pg.69 - pg.71 imply this mapping (which
is what we currently do in Tuscany):

javaToSdoMappings.put(boolean.class, "Boolean");
javaToSdoMappings.put(byte.class, "Byte");
javaToSdoMappings.put(char.class, "Character");
javaToSdoMappings.put(java.util.Date.class, "Date");
javaToSdoMappings.put(java.math.BigDecimal.class, "Decimal");
javaToSdoMappings.put(double.class, "Double");
javaToSdoMappings.put(float.class, "Float");
javaToSdoMappings.put(int.class, "Int");
javaToSdoMappings.put(java.math.BigInteger.class, "Integer");
javaToSdoMappings.put(long.class, "Long");
javaToSdoMappings.put(Object.class, "Object");
javaToSdoMappings.put(short.class, "Short");
javaToSdoMappings.put(String.class, "String");
javaToSdoMappings.put(Boolean.class, "BooleanObject");
javaToSdoMappings.put(Byte.class, "ByteObject");
javaToSdoMappings.put(Character.class, "CharacterObject");
javaToSdoMappings.put(Double.class, "DoubleObject");
javaToSdoMappings.put(Float.class, "FloatObject");
javaToSdoMappings.put(Integer.class, "IntObject");
javaToSdoMappings.put(Long.class, "LongObject");
javaToSdoMappings.put(Short.class, "ShortObject");

The only one that's not obvious in the spec is java.lang.String, since
many SDO types map to it, but mapping it to {commonj.sdo}String seems
like the right choice.

So to answer Henning's question:

> should the new open content propery "newprop" be of type
{commonj.sdo}String or rather {commonj.sdo}Date?

the answer is {commonj.sdo}Date.


Ron Barack:

When the value is a DataObject, I guess a suitable approach would be set
the type of the property to the type of the data object.

If the supplied data object is a complex as opposed to a data type, then
we need to set the "containment" property of the generated property. To
what value should it be set? One possibility would be to see if the
supplied data object already has a parent, and if so, we can assume that
the user wants the new property to reference the object, not contain it.
When the data object has no parent, then we can assume containment is
wished. These seem to me to be pretty big assumptions, and will
certainly cause confusion for our user community. Does anyone have any
better suggestions?




Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.