ProximityEObject matcher - tell the matcher that the objects are NOT equal [message #1489991] |
Thu, 27 November 2014 21:30 |
Leonid Ripeynih Messages: 150 Registered: February 2012 |
Senior Member |
|
|
Hello!
I'm comparing two models using ProximityEObject matcher but in some cases I want to customize the default behaviour.
Suppose I have the following scenario:
On branch MAIN:
+ Create Model
Create branch BRANCH
+ Add 'A' to model
Switch back to MAIN
+ Add 'B' to model
Try to merge BRANCH into MAIN.
From the EMF Comapare perspective - objects A and B are very simmilar - in fact only a single non-containment reference change is required to make A into B, so Compare does a nice job of finding that diff and reporting one change. But, from domain point of view, that reference can tell us, that the objects are entrely different, and the whole scenario should be threatened as addition of A to model. So, merge result is model with A and B separately.
I have found this ProximityEObjectMatcher.DistanceFunction.distance(...) functon, which can tell Compare framwowk, that the objects are guarenteed to be Same, but I haven't found a way to tell it that they're guarenteed to be not.
What's the right way to achive it?
Thanks in advance!
[Updated on: Fri, 28 November 2014 13:02] Report message to a moderator
|
|
|
Re: ProximityEObject matcher - tell the matcher that the objects are NOT equal [message #1494276 is a reply to message #1489991] |
Mon, 01 December 2014 10:27 |
|
Hi Leonid,
Quote:I have found this ProximityEObjectMatcher.DistanceFunction.distance(...) functon, which can tell Compare framwowk, that the objects are guarenteed to be Same, but I haven't found a way to tell it that they're guarenteed to be not.
There is no way in the ProximityEObjectMatcher to guarantee that two objects won't be matched. In the current scenario, what we would advise is to compute an ID for your elements according to the reference you want to be a match-stopper (let's say it's "name" in this example since you've used "A" and "B" as the sole discriminants).
You can say that this reference is the identifier of the EObjects that have it, so "A" will be matched with another "A", however different their content... and "A" will never be matched with "B", however similar their content. See the example to define custom identifiers in the documentation (this example uses the "name" reference of the objects of type "MyEObject" as identifier.
If you do not wish to rely on computing custom identifiers, you may want to try and set this reference to have a much higher weight in the proximity computing (see uses of the org.eclipse.emf.compare.match.eobject.WeightProvider class), but that in itself will not guarantee that EObjects with different values for this reference won't be matched when they are too similar, even with a heigh weight on it.
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.02434 seconds