Skip to main content



      Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF Compare] Correctly compare non-identifiable references
[EMF Compare] Correctly compare non-identifiable references [message #664646] Mon, 11 April 2011 09:56 Go to next message
Eclipse UserFriend
Hi,

I recently came along a problem with EMF Compare which I can not solve:

I want to compare two model instances of an Ecore meta model which exist as files. The Ecore meta model describes a very simple kind of state machines, where a state machine contains

a) a set of states (identified by a "name" attribute) and
b) a set of transitions referencing a starting and ending state and containing two attributes, "trigger" and "action", by which a transition is not identifiable!

When comparing these two files, EMF Compare generates a lot of differences which are really not present if I manually compare the two resulting state machines, but as transitions have no "identifier" and some combinations of "action" and "trigger" attributes happen to exist more than once, EMF Compare gets confused, I think.

Have you any "best practices" on comparing objects with references which are not identifiable by themselves but by their respective referenced objects?

Regards,
Johannes

Edit: I circumvented the problem by writing an own matcher for my model elements.

[Updated on: Mon, 11 April 2011 13:39] by Moderator

Re: [EMF Compare] Correctly compare non-identifiable references [message #664942 is a reply to message #664646] Tue, 12 April 2011 10:47 Go to previous messageGo to next message
Eclipse UserFriend
Hi Johannes,

In such cases, writing your own matcher is indeed the way to go, as the generic match engine of EMF Compare wouldn't be able to match your objects without help.

Laurent Goubet
Obeo
Re: [EMF Compare] Correctly compare non-identifiable references [message #665210 is a reply to message #664646] Wed, 13 April 2011 12:53 Go to previous message
Eclipse UserFriend
Hi Laurent,

as I first experienced some problems writing my own Matcher, it could be interesting for others to know that it was not sufficient to override the "isSimilar"-method only to check the similarities between elements but also to override the "findMostSimilar"-method. This was because the generic matcher matches potential similar elements by their attribute values and not, as my problem was, at given reference values.

Regards,
Johannes
Previous Topic:[EMF] Relative paths in .ecore files
Next Topic:[teneo] Hibernate Interceptor
Goto Forum:
  


Current Time: Sun Jul 13 06:15:10 EDT 2025

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

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

Back to the top