Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.6.0SDK
-
None
Description
Delta CAS serialization includes attempting to handle changes made by a remote "below the line" - changing existing FSs. If the remote removes the FSs and re-adds them back to the indices, this fact is sent back with the delta CAS as a list of FSs that are "re-indexed". The deserialization takes this list, and removes them, and re-adds them back to the indices in an attempt to get them properly indexed. However, this doesn't reliably work, if any of the keys used in the indexing were updated.
Furthermore, there is nothing that insures a remote remove/add FSs it is modifying. Perhaps the remote is unaware that FSs of that type are even being indexed (the information about what indices are defined at the client is not sent to the remote).
So, it is possible that the remote could modify some feature, which is used as a key by the client. The Deserialization would update that feature, without removing the FS from the indices first.
One conclusion - the list of "re-indexed" FSs returned by the remote during a delta serialization is not a reliable indication of which FSs would need reindexing, since the index definitions between the client and the remote could be different.
One fix: for mods to existing FSs, remove the FS from the indices in each view, do the mods, and then add them back (if they were previously found in the indices for that view). Some optimizations: for subtypes of AnnotationBase - only one view need be checked. The remove could be skipped if none of the slots being updated are in use as keys in some index; this might be an expensive check, though.
This is a problem for all implementations that support Delta CAS: Xmi, Binary, BinaryCompressed types 4 and 6.