Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF Diff/Merge » Structural comparison of two model trees
Structural comparison of two model trees [message #1021809] Wed, 20 March 2013 18:08 Go to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 295
Registered: March 2012
Senior Member

I'd like to implement a custom IMatchPolicy that provides a comparable for which two elements are identical if their "path" with respective to a given (common) root element is the same, AND if they have the same type. I thought the default URIs provided by ResourceImpl are a fine way to get such a comparable, so see below.
The question is whether it is really neccessary to incrust the name of the element's classifier into the result string, or if Diff/Merge detects automatically that the type of two matched objects is not the same?

      public Comparable<?> getMatchId(EObject element_p, IModelScope scope_p) {
        InternalEObject scopeRoot = ((InternalEObject)((SubtreeModelScope) scope_p).getRoot());
        InternalEObject internalElement = (InternalEObject)element_p;
        List<String> uriFragmentPath = new ArrayList<String>();
        HashSet<InternalEObject> visited = new HashSet<InternalEObject>();
        for (InternalEObject container = internalElement.eInternalContainer(); container != scopeRoot.eContainer() && visited.add(container); container = internalElement.eInternalContainer()) {
          uriFragmentPath.add(container.eURIFragmentSegment(internalElement.eContainingFeature(), internalElement));
          internalElement = container;
        // we incrust the element's class name into the comparable to only match elements of the same type
        StringBuffer result = new StringBuffer(element_p.eClass().getName() + "#//");
        for (int i = uriFragmentPath.size() - 1; i >= 0; --i) {
        return result.toString();

Re: Structural comparison of two model trees [message #1022769 is a reply to message #1021809] Fri, 22 March 2013 13:38 Go to previous message
Olivier Constant is currently offline Olivier ConstantFriend
Messages: 106
Registered: January 2012
Senior Member
Hello Felix,

Matching elements of different types is not forbidden, although support for this situation is currently limited. The structural features which are tested for differences will be those of (the type of) the element from the TARGET side. If the element from the REFERENCE side is of a type that does not have one of these features, then the element will simply be considered as having no value on the feature.

If your matching algorithm is not based on Ecore/XML IDs and you wish to prevent two elements of different types from being matched, you should indeed take care that the match IDs (Comparable) you return have an 'equals' method which returns false when the types are different.

You can proceed as you propose with Strings. My hint would be to use more structured, higher-level data: you may use for example the 'getQualifiedName' method of DefaultMatchPolicy in order to get a ComparableSequence. You may aggregate ComparableSequence into a Comparable that also takes the type of the model element into account.

Hope it helps.

Previous Topic:How to compare unordered list
Next Topic:Ignore differences on attribute 'x' on elements of type 'y'
Goto Forum:

Current Time: Mon Apr 22 07:41:24 GMT 2024

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

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

Back to the top