| [CDO] CDORevisionData.NIL in revision deltas - not supported? [message #1036840] |
Mon, 08 April 2013 22:15  |
|
Hi, Eike,
In investigation of problems in handling explicit null values of
unsettable attributes, it appears to me that CDORevisionData.NIL cannot
be transmitted to the server as the new value in a
CDOSingleValueFeatureDeltaImpl.
Running the test case contributed in this attachment:
https://bugs.eclipse.org/bugs/attachment.cgi?id=229404
on this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=404152
also used by this follow-up bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405191
I see that the reason why the test fails is that the revision delta
created as a result of the CDOLegacyAdapter::notifySet(...) method
pushing the "new value" of an unsettable feature into the CDOStore has
a Java null as the new value instead of CDORevisionData.NIL.
When the revision for a new object has a CDORevisionData.NIL value for
some attribute, there is no problem sending it to the server. Another
client reading this revision from the server gets the NIL value and
correctly translates it to an explicit null (is-set) value of the
unsettable feature.
But for objects that already exist, the client sends revision deltas
(containing feature deltas) to the server. In an attempt to fix
405191, I changed the legacy adapter to ensure that the new-value in
the feature delta is CDORevisionData.NIL when an unsettable feature is
changed to an explicit (is-set) null value. This results in a
ClassCastException (see trace, below) when writing the feature delta to
a CDODataOutputImpl delegates the the CDOTypeImpl.STRING to write the
value, but this tries to cast the NIL to a String.
Note that the same ClassCastException occurs when trying run the test
case from the above-linked attachment in a native (not legacy) test
configuration. It would seem that native models don't support
unsettable attributes of EString type at all.
So, the bottom line is: are unsettable attributes supposed to be
supported by CDO in attributes of EString type (and BooleanObject,
IntegerObject, FloatObject, etc.)? If so, I don't know how I can
safely update the communication protocol for revision deltas on the
client and server ends to support whatever backward/forward
compatibility of the protocol might be required.
I've pushed the test case (with changes to model6) to the bugs/405191
branch in Git, so it should be easy to check it out and run to see what
I mean.
Thanks,
Christian
|
|
|
|
Powered by
FUDForum. Page generated in 0.02982 seconds
] 
Search
Help
Register
Login
Home
