| Enhacement proposal on IdentifierEObjectMatcher [message #1066431] |
Tue, 02 July 2013 15:55  |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi folks,
after a couple of months using the new 2.1.0 release, we identified a possible enhacement in the IdentifierEObjectMatcher implementation.
IdentifierEObjectMatcher has an IEObjectMatcher delegation mechanism which is pretty convenient. However, the delegation only happens in case no ID is calculated for an arbitrary EObject (in practices, when ID are returned as null). In case the ID is calculated, then its either matched or it is not. If a match is NOT found for an Identifiable EObject, it is always considered ADDED / DELETE. We found that identified but not matched EObjects always ended up ADDED / DELETE, and although its coherent with the concept of unique ID, this scenario could become more flexible by adding another delegation condition.
We found desirable that, if an EObject is suitable for identification (the ID was calculated), but not matched (no match with the same ID was found), that EObject could be passed to the delegated IEObjectMatcher. This means, we are giving an identified-but-not-matched EObject a second chance. Maybe the ProximityMatcher founds a good match for it.
I understand the above may not be desirable to all clients, so we could leave the current behavior as the default, but let clients configure this.
I could create my own IEObjectMatcher implementation with this behavior,
but duplicating a whole class to change a couple lines of code does not seem right.
The right place to introduce this is
IdentifierEObjectMatcher.createMatches(Comparison, Iterator<? extends EObject>, Iterator<? extends EObject>, Iterator<? extends EObject>, Monitor)
Let me share the custom code we added to this method:
List<Match> matchesToPassToProximityMatcher= new ArrayList<Match>();
for (Match match : matches) {
EObject left = match.getLeft();
EObject right = match.getRight();
if (left != null && right == null) {
if (isExcludibleFromIdMatch(left)) {
matchesToPassToProximityMatcher.add(match);
leftEObjectsNoID.add(left);
}
}
if (left == null && right != null) {
if (isExcludibleFromIdMatch(right)) {
matchesToPassToProximityMatcher.add(match);
rightEObjectsNoID.add(right);
}
}
}
matches.removeAll(matchesToPassToProximityMatcher);
(Note we don't check origin, as we never use three-way comparisons).
In our case, we went further with this delegation, and we made it happen
only for a subset of the model's EClasses (the isExcludibleFromIdMatch() method)
My proposal would be to introduce a simple protected method that lets
the client process the Set<Match> matches, and the left/right/origin EObjects lists,
right before it enters the delegation mechanism. That way i can subclass IdentifierEObjectMatcher and introduce the above logic in that method. Maybe
other clients find another interesting restrictions.
Hope I was clear enough. Do you guys find this proposal interesting enough to be implemented?
|
|
|
| Re: Enhacement proposal on IdentifierEObjectMatcher [message #1066557 is a reply to message #1066431] |
Wed, 03 July 2013 07:32  |
|
Seems fair to me. Could you raise a bugzilla with this use case and the proposed solution? It looks like we could simply extract a protected method for the body of the if (delegate.isPresent()) { ... }
Laurent Goubet
Obeo
|
|
|
|
Powered by
FUDForum. Page generated in 0.03164 seconds
] 
Search
Help
Register
Login
Home
