Undo throws 'no duplicates' constraint in eclipse 4.2.2

[pcdavid]

• 🆔 Bugzilla ID: #406309
• 📘 Project: Modeling / EMF Services / Transaction
• 🗓 Created: 2013-04-23T11:05:12Z
• ❓ Status: NEW /

[pcdavid]

Comment #0 on Tue Apr 23 2013 13:05:12 GMT+0200 (Central European Summer Time):

Our product has recently moved from eclipse 3.6 to eclipse 4.2.2 and 
emf version 2.6 to 2.8.

After the migration we are facing problem in undo of few elements.
It is violating Unique Constraint and throwing a "no duplicate" constraint violation.

Attaching the debug trace for undo action .

---

Comment #1 on Tue Apr 23 2013 18:09:20 GMT+0200 (Central European Summer Time):

Sarika,

I will need a test case that reproduces this problem, not just a screen capture of stack trace.  That test case will need to be something that I can run locally with just EMF installed.  If it involves installing other things, the originators of those other things will need to diagnose the problem and produce an self-contain EMF test case.  So pending something more meaningful from you, I'll assign this to EMF transaction as that appears necessary to reproduce the problem, i.e., its on the stack.

---

Comment #2 on Fri May 10 2013 12:17:09 GMT+0200 (Central European Summer Time):

Hi,
I tried creating a scenario in Vanilla Eclipse but did not succeed. 

So I tried debugging this scenario and the scenario is that we have issues when we are trying to delete an object which has an association and this association has a destroy advice to destroy source and targets. Duplicate entry comes for this association element.


while debugging my observation is that in method below:

org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.preApply(boolean) method :
 EList<Object> applyToList = new BasicEList<Object>((EList<?>)objectToChange.eGet(internalFeature));
              for (ListChange listChange : featureChange.getListChanges())
              {
                listChange.applyAndReverse(applyToList);
              }
              featureChange.setValue(applyToList); 


What happens here is that the applytoList has duplicate entries of associations after the listChange.applyAndReverse execution. But this not create a problem many times and it create problem only if the last entry is repeated in applyToList as  the execution of ECollections.setEList(result, prototype);
in org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.process(EObject, boolean, boolean) is not able to take care of duplicates if it is in the last and position will not be -1 in such a scenario and it will blindly add the last element in the elist as eList.add(index, prototypeObject); in org.eclipse.emf.common.util.ECollections.setEList(EList<T>, List<? extends T>)

Our previous version of product was using emf 2.5.1 and the Change list has totally changed from then so I am not bale to find the exact diiference in step which is causing this.

Let me know if I can provide some debugging key points or let me know if I should analyze a particular element or method to understand this better and come to solution.

---

Comment #3 on Wed Oct 02 2013 19:18:34 GMT+0200 (Central European Summer Time):

Hi Ed, is the information provided by Sarika helpful for isolating the issue?

---

Comment #4 on Thu Dec 12 2013 16:38:44 GMT+0100 (Central European Standard Time):

Adding Vikas

---

Comment #5 on Sat May 14 2022 15:51:46 GMT+0200 (Central European Summer Time):

Eclipse EMF Transaction is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/emf-transaction.

If this issue is relevant to you and still present in the latest release:

* Create a new issue at https://github.com/eclipse/emf-transaction/issues/.
  * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  * In the GitHub description, start with a link to this bugzilla ticket
  * Optionally add new content to the description if it can helps towards resolution
* Update bugzilla ticket
  * Add to "See also" property (up right column) the link to the newly created GitHub issue
  * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  * Set status as CLOSED MOVED

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for EMF Transaction will be archived and made read-only.