Community
Participate
Working Groups
Build Identifier: 20110218-0911 I'm currently working with the ModelGenerator and the ModelChanger. I created a test case where I generate a model, put it into the emfstore, check it out again and compare it with the local version. This works fine. But when deleting elements from the model, using the EcoreUtil.delete()- method (as implemented in the generator/changer) then this changes are applied wrong. What happens is, that elements on the root level aren't deleted at all. Elements on other levels, are moved to the root level instead of being deleted. I created a test case in a copy of the org.eclipse.emfstore.client.test project I host at github. Reproducible: Always Steps to Reproduce: 1.Check out the org.eclipse.emf.emfstore.client.test, org.eclipse.emf.emfstore.modelgenerator,org.eclipse.emf.emfstore.modelgenerator.common,org.eclipse.emf.emfstore.modelgenerator.ui and the org.eclipse.example.bowlingmodel,org.eclipse.example.bowlingmodel.edit from git://github.com/eneufeld/EmfStore-Test.git 2.in org.eclipse.emf.emfstore.client.test.server run the AllServerTest Test-Suite 3.a good way to see what happens, is to set a breakpoint in line 143 of the ModelGeneratorTest class in the same package as the AllServerTest. in the .emfstore folder you can see the current model under client and the two versions of the store in the server folder.
Hi Eugen, I just sent you a pull-request on github. It looks like the EObject itself remains on the root-level because only an EObjects references, such as the containment reference to the objects parent, is removed when deleting it. The problem is that an EObject is only considered deleted, if it is no longer connected to the containment tree at the end of a command. (We consider a command to represent a consistent set of changes to a model.) You could use a DeleteCommand or an AbstractCommand to persistently delete an EObject. However the bug you reported is of course valid and the framework should make it more clear if elements are removed without a command, therefore I open this bug to implement a warning: https://bugs.eclipse.org/bugs/show_bug.cgi?id=367101 I hope this helps.
