| Comparing two structurally equal EObjects yields PSEUDO conflict [updated] [message #1757980] |
Wed, 22 March 2017 10:06  |
Eclipse User |
|
|
|
Let's say I have this simple model (Xcore syntax):
class A {
contains B[] bs opposite a
}
class B {
String foo
container A a opposite bs
}
I now have three A's, created like the following:
A a1 = ModelFactory.eINSTANCE.createA();
B b1 = ModelFactory.eINSTANCE.createB();
b1.setFoo("foo");
b1.setA(a1);
A a2 = ModelFactory.eINSTANCE.createA();
B b2 = ModelFactory.eINSTANCE.createB();
b2.setFoo("bar");
b2.setA(a2);
A a3 = ModelFactory.eINSTANCE.createA();
B b3 = ModelFactory.eINSTANCE.createB();
b3.setFoo("bar");
b3.setA(a3);
When I try to compare them like this:
DefaultComparisonScope scope = new DefaultComparisonScope(a1, a2, a3);
Comparison comp = EMFCompare.builder().build().compare(scope);
EList<Diff> diffs = comp.getDifferences();
I am expecting to get one attribute change on the B__FOO EAttribute, but I get two pseudo conflicts for the ADD kind for A__BS. I think this is because of how EMF handles equality, and the A's and B's are, technically, different.
How do I achieve that I get the "correct" differences?
EDIT: I now started with a clean project with this very simple example (but with a UUID property added to each of the classes as it is also the case with my "real" model I cannot post here) and it worked.
So can anyone guide me what can be the culprit that the diffs get recognized incorrectly in my real model? Things to look at to narrow down the origin of the problem?
[Updated on: Wed, 22 March 2017 13:24] by Moderator |
|
|
|
| Re: Comparing two structurally equal EObjects yields PSEUDO conflict [updated] [message #1758058 is a reply to message #1758056] |
Thu, 23 March 2017 04:27  |
| Eclipse User |
|
|
|
In the meantime, I found the cause myself. I did not correctly load / update the "common ancestor" in my real model.
So, I constructed the left side from the files in my project, the right side from the current state in the database, and the common ancestor was the database state when creating the project. When committing changes, I forgot to update the common ancestor to the state after the commit - it was still the old one. Thus, I was comparing my previous commit and my new commit to the old outdated state which yielded this incorrect result.
|
|
|
Powered by
FUDForum. Page generated in 0.04449 seconds
Home