Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Questions on custom IMatchEngines
Questions on custom IMatchEngines [message #1341025] Thu, 08 May 2014 09:31 Go to next message
Andreas Mayer is currently offline Andreas MayerFriend
Messages: 11
Registered: April 2014
Junior Member
Hi,

I've implemented a custom IMatchEngine for my model. It's basically working, but I still have some questions that I couldn't answer by reading the documentation or browsing the code:
  • How are you supposed to implement IMatchEngine.Factory.isMatchEngineFactoryFor(IComparisonScope)?

    When this method is called in my factory (run by Compare With > Each Other in the IDE), both IComparisonScope.getNsURIs() and IComparisonScope.getResourceURIs() return an empty set. So my implementation iterates over the contents of left, right, and origin to see if there is any object from my model package. The default implementations all just return true. Is there a better way?
  • As far as I can see, an IMatchEngine should structure the detected matches to resemble the structure of the input models. Is this also true for non-matches? ProximityEObjectMatcher always restructures matches in a final step, whereas IdentifierEObjectMatcher adds non-matches as roots if there is no delegate matcher.
  • Since all IEObjectMatchers are required to create this match hierarchy, shouldn't it rather be done as some kind of post-processing in DefaultMatchEngine. Especially when considered that IEObjectMatchers can be chained as done in IdentifierEObjectMatcher.

Thanks,
Andreas

Re: Questions on custom IMatchEngines [message #1352091 is a reply to message #1341025] Tue, 13 May 2014 09:48 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1843
Registered: July 2009
Senior Member
Hi Andreas,



  • The default match engines are all applicable on any metamodel, so they don't need anything smarter than this "return true"... though that means there are no real example of that in the code base. "getResourceURIs" and "getNsURIs" from the comparison scope are two lazily populated sets, so you won't get anything in there before first iterating on the scope's covered elements. Iteration is thus your only way to determine whether the scope contains something you're interested in or not... though you'd probably be better with a condition such as "if getResourceURIs() is empty, then iterate, otherwise look if one of these URIs is interesting". This will avoid multiple subsequent iterations if you've already done it once on this scope.
  • The implementation of ProximityEObjectMatcher restructures the matches, and the IdentifierEObjectMatcher properly adds non matches at their rightful place right when they're found. However, when EObjects don't have identifier and there is no delegate matcher (which we hope to be very rare an occurence : it should not happen with XMI:IDs at least), the IdentifierEObjectMatcher does not add non-matches (as opposed to adding it at its root as you mention), it will do so however once gerrit change 26141 is merged... though indeed the very quick implementation I made on this change is wrong : it should restructure the matches before adding them. I'll modify the gerrit change before we push it.
  • We didn't intend to make this hierarchy mandatory, and the default diff engine and post processors should be able to cope with a wrong hierarchy. The UI does rely on it to properly display a coherent model to the user though... It might indeed be better to have it done as a post-processing in DefaultMatchEngine, but at the cost of speed since it will need a full iteration on the comparison model. This will have to be thought out more.


Laurent Goubet
Obeo
Re: Questions on custom IMatchEngines [message #1366816 is a reply to message #1352091] Mon, 19 May 2014 13:44 Go to previous messageGo to next message
Andreas Mayer is currently offline Andreas MayerFriend
Messages: 11
Registered: April 2014
Junior Member
Thanks for your reply, Laurent.

"Laurent Goubet wrote"

The default match engines are all applicable on any metamodel, so they don't need anything smarter than this "return true"... though that means there are no real example of that in the code base. "getResourceURIs" and "getNsURIs" from the comparison scope are two lazily populated sets, so you won't get anything in there before first iterating on the scope's covered elements. Iteration is thus your only way to determine whether the scope contains something you're interested in or not... though you'd probably be better with a condition such as "if getResourceURIs() is empty, then iterate, otherwise look if one of these URIs is interesting". This will avoid multiple subsequent iterations if you've already done it once on this scope.

That's a good advice.

Quote:

We didn't intend to make this hierarchy mandatory, and the default diff engine and post processors should be able to cope with a wrong hierarchy. The UI does rely on it to properly display a coherent model to the user though... It might indeed be better to have it done as a post-processing in DefaultMatchEngine, but at the cost of speed since it will need a full iteration on the comparison model. This will have to be thought out more.

I've already noted myself that the UI makes some implicit assumptions, e.g. that the match tree is consistent with the model structure, because it is used to group the diffs or that non-containment changes are deemed unimportant (and therefore are omitted in the structure viewer) if there are containment changes on the parent. As far as I understand now, the engines are not strictly required to meet these assumptions, but if you want to show a comprehensible result in the UI, then they better do. Maybe these assumptions should be documented somewhere?

Andreas

Re: Questions on custom IMatchEngines [message #1371042 is a reply to message #1366816] Wed, 21 May 2014 07:31 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1843
Registered: July 2009
Senior Member
Hi,

Quote:

non-containment changes are deemed unimportant (and therefore are omitted in the structure viewer) if there are containment changes on the parent.


It's not that we deem them unimportant, but we expect most users to see them as "noise". These diffs are actually filtered out by default, but can be seen individually by disabling the "cascading differences" filter.

The reason this filter is active by default is that merging a sub-diff of a containment difference usually requires the merging of that difference anyway.

Quote:

As far as I understand now, the engines are not strictly required to meet these assumptions, but if you want to show a comprehensible result in the UI, then they better do. Maybe these assumptions should be documented somewhere?


They should be. Those are assumptions that we made in the GUI and we haven't taken the time to document them properly as there are always more pressing matters to attend to Razz.

Laurent Goubet
Obeo
Previous Topic:[EMF Compare] Register custom EMF models for comparison
Next Topic:CascadingDifferencesFilter and changes in moved objects
Goto Forum:
  


Current Time: Wed Jan 17 07:42:32 GMT 2018

Powered by FUDForum. Page generated in 0.01836 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software