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

Bug 216676

Summary:

[EMF-Databinding] EObjectObservableMap improperly handles changes when more than one EStructuralFeature is Mapped

Product:

[Modeling] EMF

Reporter:

Trevor <endante>

Component:

Core

Assignee:

Marcelo Paternostro <marcelop>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

Ed.Merks, nboldt

Version:

2.4.0

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
patch to fix bug	none
Compare against the actual feature instance	none

Description Trevor

2008-01-26 14:17:08 EST

Build ID: I20071213-1700

Steps To Reproduce:
Create ObservableMap of  2 different features of the same EObject. When one feature changes, all features are updated to this value. Doesn't filter change handling by the feature

More information:
Will attach a a patch which should fix the issue.

Comment 1 Trevor

2008-01-26 14:22:52 EST

Created attachment 87947 [details]
patch to fix bug

Comment 2 Ed Merks

2008-01-26 15:53:20 EST

Created attachment 87949 [details]
Compare against the actual feature instance

This approach is more efficient (and correct).  You have to be very careful when using EStructuralFeature.getFeatureID anywhere because this is not necessarily the ID that will be used with any particular class.  If the feature is inherited by multiple inheritance rather than as the first super class, the IDs in that class will be offset.  I.e., x.getFeatureID and eClass.getFeatureID(x) might not be == for the same feature instance x.  It's very tricky.  :-(

We need to find time to deal with the TODO case as well, i.e., for multi-valued features.  If you'd care to create a test case, I'd be happy to help make the scenario work properly...

Thanks for the testing and for supplying patches!

Comment 3 Ed Merks

2008-01-26 16:02:43 EST

The changes are committed to CVS for 2.4.  I changed it slightly more to test the feature before testing is touch, since 99% of the time touch will be false and it's just as likely to be for a different feature in which case isTouch doesn't need to be tested.  I made corresponding changes for list and value (and changed them to use == for the feature rather than .equals).

Comment 4 Nick Boldt

2008-01-28 18:22:32 EST

The changes are committed to CVS for 2.4.

Comment 5 Nick Boldt

2008-01-30 00:04:07 EST

Fix available in HEAD: 2.4.0.I200801292000.