Bug 352040 - EObjectObservableList incorrect removeAll()/clear() diff
Summary: EObjectObservableList incorrect removeAll()/clear() diff
Status: NEW
Alias: None
Product: EMF
Classification: Modeling
Component: Edit (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Thomas Schindl CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-13 21:27 EDT by Maxim Gordienko CLA
Modified: 2011-08-05 14:33 EDT (History)
2 users (show)

See Also:


Attachments
The complete test project (16.21 KB, application/x-zip-compressed)
2011-07-13 21:28 EDT, Maxim Gordienko CLA
no flags Details
Patches to address the issue. (1.43 KB, patch)
2011-07-14 13:03 EDT, Ed Merks CLA
no flags Details | Diff
Working in Progress Patch (21.40 KB, patch)
2011-08-05 12:33 EDT, Thomas Schindl CLA
no flags Details | Diff
Working in Progress Patch (25.01 KB, text/plain)
2011-08-05 14:33 EDT, Thomas Schindl CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim Gordienko CLA 2011-07-13 21:27:07 EDT
Build Identifier: M20110210-1200

The indices in a ListDiff event fired by EObjectObservableList during a multi-remove operation (removeAll()/clear()) are incorrect.

The problem (as I can see it) is in the implementation of the
Notification.REMOVE_MANY case in the Adapter created in
EObjectObservableList#firstListenerAdded()

The index computation is incorrect. It should take the removed element
into account not just blindly increment the index. (see how the diff
is calculated in WritableList#clear())

Another problem is with clear(). The notification event index will be
set to Notification.NO_INDEX which is -1. (see
NotifyingListImpl#clear())

Reproducible: Always

Steps to Reproduce:
               Container container = FACTORY.createContainer();
               container.getComponents().add(FACTORY.createComponent());
               container.getComponents().add(FACTORY.createComponent());
               IObservableList list = EMFObservables.observeList(container,
PACKAGE.getContainer_Components());

               Listener listener = new Listener();
               list.addListChangeListener(listener);

               list.clear();

               assertEquals(Arrays.asList(0, 0), listener.getIndices());
               // The actual indices are [-1, 0]
Comment 1 Maxim Gordienko CLA 2011-07-13 21:28:40 EDT
Created attachment 199630 [details]
The complete test project

Contains the eclipse project directory (ECore model, generated artifacts and the full test case).
Comment 2 Ed Merks CLA 2011-07-14 13:03:15 EDT
Created attachment 199687 [details]
Patches to address the issue.

I've not tested these changes, but the idea is that the REMOVE_MANY notification includes an array with the positions of the removals, except in the case where the array is basically redundant because it's just the sequence of values 0..n, i.e., when you clear the list.
Comment 3 Ed Merks CLA 2011-07-14 13:13:30 EDT
Tom,

The same issue comes up in EMFResourceContentProperty and EWritableList whereas EMFPropertyListener is done correctly.
Comment 4 Thomas Schindl CLA 2011-08-05 12:33:18 EDT
Created attachment 200999 [details]
Working in Progress Patch

* I've synced the listeners to be all the same than the one in EMFPropertyListener
  - Ed it looks like there's been also a difference in the resolve case can you 
    you clarify which one is correct (i currently assumed the one in 
    EMFPropertyListener)
* I've ported your patch to our test suite 

* TODOs:
  - The writeable list test fails (maybe a bug in core databinding??)
  - add test for property-api
  - add test for edit-api
Comment 5 Thomas Schindl CLA 2011-08-05 14:33:18 EDT
Created attachment 201009 [details]
Working in Progress Patch

I've now added a test for the property and there the list-diff is like the one in WritableList. The logic in there seems to be [1,0] I think we should yield the same in our listeners not?