| Implementing IEObjectMatcher [message #1819268] |
Fri, 10 January 2020 22:15  |
 Steve Hickman
Messages: 13
Registered: January 2017 |
Junior Member |
|
|
EMF Compare lets me create multiple Matchers and daisy chain them together so that if one Matcher fails to determine an ID for an EObject, the next one in the chain will be called.
What if there multiple ways to Match something, with some providing a better match than others, how do I make sure the correct Match is made?
Creating customized MatchEngines, each with a different Matcher, only helps if the IComparisonScope changes. In my case, the same two objects could match based on:
1) IQualifiedName
2) Partial IQualifiedName
3) A common reference
4) A common second order reference
5) Type (possibly)
First, I want to match everything I can on a full IQualifiedName. For any unmatched EObjects, I want to match on a partial IQualifiedName wherever possible. For any remaining unmatched EObjects, I want to match if they share a common reference. And so on.
It looks like I need a custom implementation of IEObjectMatcher.
My questions are:
1) Is this what I need to do? If not, what should I be looking at?
2) Does there already exist some generic implementation of IEObjectMatcher that can daisy chain standard IEObjectMatcher implementations dynamically?
3) Is there any documentation other than the code that I should be looking at?
[Updated on: Fri, 10 January 2020 22:16] Report message to a moderator |
|
|
| Re: Implementing IEObjectMatcher [message #1819643 is a reply to message #1819268] |
Mon, 20 January 2020 08:53  |
|
Hello Steve,
The only other way to match EObjects together would be to customize the IDFunction but it doesn't look like this would help in your case since your rules look more like chaining than defining a customized identifier.
Customizing the IEObjectMatcher seems to be the way to go in your case as long as you know the specific rules with which to match. Note that the chaining strategy implemented by the EMF Compare IdentifierEObjectMatcher will only pass the EObject that have no identifier to the delegate matcher. You will probably not inherit from that matcher though, but you can implement a different chaining mechanism for your own needs : as long as the matcher hasn't returned from its "match" method, you can modify the Match model at will. Just make sure that no two objects are referenced in two different Match objects (you can also look at the ProximityEObjectMatcher which completely restructures the matches before returning).
Looking at your rules for matching, I wonder if you won't have to also reimplement a custom IEqualityHelper for the remainder of the process (differencing, equivalences, conflict detection, merging, ...). You might want to keep that in mind if some of the merging doesn't work as you expect.
The only documentation we have is what you can find for the developer guide but I think you have already found that one. The code will likely be more useful for you as far as matcher implementations go though.
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.01806 seconds
] 
Search
Help
Register
Login
Home
