Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330903

Summary: Improve hashcode & equals Implementation for CDOFeatureDeltas
Product: [Modeling] EMF Reporter: Pascal Lehmann <pascal.lehmann>
Component: cdo.coreAssignee: Pascal Lehmann <pascal.lehmann>
Status: CLOSED FIXED QA Contact: Eike Stepper <stepper>
Severity: normal    
Priority: P3    
Version: 4.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch v1
none
Patch v2 - ready to be committed none

Description Pascal Lehmann CLA 2010-11-23 06:34:09 EST 
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?
Comment 1 Eike Stepper CLA 2010-11-27 01:42:17 EST 
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 ;-(
Comment 2 Eike Stepper CLA 2010-11-27 01:42:36 EST 
Created attachment 183973 [details]
Patch v1
Comment 3 Eike Stepper CLA 2010-11-29 04:34:41 EST 
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.
Comment 4 Eike Stepper CLA 2010-11-29 04:35:44 EST 
Only while comparing feature deltas in a merge (where the delta is not used as a *key*) the new isStructurallyEqual() method is used.
Comment 5 Pascal Lehmann CLA 2010-11-29 09:40:18 EST 
Committed Patch v2 to HEAD.
Comment 6 Eike Stepper CLA 2011-06-23 03:37:38 EDT 
Available in R20110608-1407