Community
Participate
Working Groups
There are some cases where the hashcode or equals method of a CDOFeatureDelta will return the same result or true when it's not the same CDOFeatureDelta. Examples are CDOMoveFeatureDelta on the same feature with same indices, CDORemoveFeatureDelta without objects (I think there are still cases where the object is not present?) on the same index & feature, CDOAddFeatureDelta with the same object and index & feature on non-unique lists. I guess it can also cause problems for different CDOSetFeatureDeltas with the same content, eg. when using ConflictResolving with more than one SavePoint. This might cause unexpected results whenever working with CDOFeatureDeltas as Keys in HashMaps (eg. CDOListFeatureDeltaImpl.copy()), or when working with Lists of CDOFeatureDeltas. I'm unsure how we shall solve this problem. Maybe a transient random number which is generated upon creation of the delta (and copied whenever a copy is made) and taken into the hashcode/equals calculation is already enough?
Hard to determine in what places we want value comparison and in what other places we want pointer comparison. Or do you think we can go with pointer comparison in all cases? If we need both approaches we could use the changes in patch v1 and a HashMap that supports overriding the hash code and equals function that is used for the elements, java.util.HashMap does not support this ;-(
Created attachment 183973 [details] Patch v1
Created attachment 184016 [details] Patch v2 - ready to be committed This patch removes all hashCode() and equals() implementations from all feature deltas. The default pointer equality is used instead.
Only while comparing feature deltas in a merge (where the delta is not used as a *key*) the new isStructurallyEqual() method is used.
Committed Patch v2 to HEAD.
Available in R20110608-1407
