Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Child comparison problem(EMF Compare incorrectly compares same-name children of different parents)
icon5.gif  Child comparison problem [message #534562] Wed, 19 May 2010 14:31 Go to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Hello,

I will be glad for any advice on how to overcome the problem I've encountered when using EMF compare on my model. The essence of the problem is the following:

Let's say I have a model with two objects at root: A and B. Both have a child named C (same name, but different content). When I compare the two copies of the model there are obviously no differences. But as soon as I make a change to one model, say add a new object D to a root, I get not just one difference (D has been added), but three (B.C removed, B.C added, D added).

What I have at the moment is a custom MatchEngine with overridden methods isSimilar(...), findMostSimilar(...) etc. I'd like to know what must be implemented to fix this issue?

Regards,
Vitaly

[Updated on: Wed, 19 May 2010 14:31]

Report message to a moderator

Re: Child comparison problem [message #534728 is a reply to message #534562] Thu, 20 May 2010 07:24 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010702090606010302060400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Vitaly,

The "isSimilar()" method you overrode in your custom match engine is
what's causing problems here. Namely, if "isSimilar()" returns false for
your objects "B.C" for any reason, you will get two diffs : "B.C has
been removed" and "B.C has been added".

You'll have to double check your implementation of isSimilar to find why
you're returning false when the two parameters are your "C" objects.

Laurent Goubet
Obeo

Vitaly Savickas wrote:
> Hello,
>
> I will be glad for any advice on how to overcome the problem I've
> encountered when using EMF compare on my model. The essence of the
> problem is the following:
>
> Let's say I have a model with two objects at root: A and B. Both have a
> child named C (same name, but different content). When I compare the two
> copies of the model there are obviously no differences. But as soon as I
> make a change to one model, say add a new object D to a root, I get not
> just one difference (D has been added), but three (B.C removed, B.C
> added, D added).
>
> What I have at the moment is a custom MatchEngine with overridden
> methods isSimilar(...), findMostSimilar(...) etc. I'd like to know what
> must be implemented to fix this issue?
>
> Regards,
> Vitaly


--------------010702090606010302060400
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------010702090606010302060400--
Re: Child comparison problem [message #534776 is a reply to message #534728] Thu, 20 May 2010 10:09 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Thanks Laurent.

Yes, I understand that isSimilar(...) must be responsible for that, but this is also the reason I am confused about this problem: when I debugged the whole compare process of two models isSimilar(...) was always true. I've also noticed that it didn't even get called on the B.C. I have a slight guess that it makes an assumption on the list of objects matched by their names and after C has matched it is never looked at again, but I'm not familiar with the algorithm so sorry if I'm wrong. Any ideas on why is it behaving this way?

Vitaly

[Updated on: Thu, 20 May 2010 10:20]

Report message to a moderator

Re: Child comparison problem [message #534931 is a reply to message #534776] Thu, 20 May 2010 16:34 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Vitaly Savickas wrote on Thu, 20 May 2010 06:09
Thanks Laurent.

Yes, I understand that isSimilar(...) must be responsible for that, but this is also the reason I am confused about this problem: when I debugged the whole compare process of two models isSimilar(...) was always true. I've also noticed that it didn't even get called on the B.C. I have a slight guess that it makes an assumption on the list of objects matched by their names and after C has matched it is never looked at again, but I'm not familiar with the algorithm so sorry if I'm wrong. Any ideas on why is it behaving this way?

Vitaly


I've investigated it further and revealed that isSimilar(...) is ignored for B.C because of this bit of code in the mapLists(...) method of GenericMatchEngine:
	...
	final StringBuilder obj1Key = new StringBuilder();
	obj1Key.append(NameSimilarity.findName(obj1));
	obj1Key.append(obj1.hashCode());
	EObject obj2 = matchedByID.get(obj1Key.toString());
	...
	if (notFoundList1.contains(obj1) && notFoundList2.contains(obj2) && isSimilar(obj1, obj2)) {
		...
	}

in which matchedByID returns me the same A.C for B.C. Those two are obviously not the same and the condition doesn't hold. This happens because the matchedByID map is constructed on the object IDs, and my model treats the names as IDs. It is incorrect in a sense that there are two C objects of the same ID, but we have no problems with this for now. So can anyone please suggest is there a way to match it not just by IDs? Can this mechanism be overridden?

Vitaly
Re: Child comparison problem [message #535057 is a reply to message #534931] Fri, 21 May 2010 08:04 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi Vitaly,

If you want to ignore this ID attribute you should pass the corresponding
options (for intrinsic or XMI ID's:

Map options = new HashMap();
options.put(MatchOptions.OPTION_IGNORE_XMI_ID, Boolean.TRUE);
options.put(MatchOptions.OPTION_IGNORE_ID, Boolean.TRUE);


As a sidenote I fixed a regression about the root elements matching this
week, it would be safer for you to use the RC1 (or the CVS HEAD).

Cheers,

Cédric

Vitaly Savickas wrote:

> Vitaly Savickas wrote on Thu, 20 May 2010 06:09
>> Thanks Laurent.
>>
>> Yes, I understand that isSimilar(...) must be responsible for that, but
>> this is also the reason I am confused about this problem: when I debugged
>> the whole compare process of two models isSimilar(...) was always true.
>> I've also noticed that it didn't even get called on the B.C. I have a
>> slight guess that it makes an assumption on the list of objects matched
>> by their names and after C has matched it is never looked at again, but
>> I'm not familiar with the algorithm so sorry if I'm wrong. Any ideas on
>> why is it behaving this way?
>>
>> Vitaly
>
>
> I've investigated it further and revealed that isSimilar(...) is ignored
> for B.C because of this bit of code in the mapLists(...) method of
> GenericMatchEngine:
>
> ...
> final StringBuilder obj1Key = new StringBuilder();
> obj1Key.append(NameSimilarity.findName(obj1));
> obj1Key.append(obj1.hashCode());
> EObject obj2 = matchedByID.get(obj1Key.toString());
> ...
> if (notFoundList1.contains(obj1) && notFoundList2.contains(obj2) &&
> isSimilar(obj1, obj2)) { ...
> }
>
> in which matchedByID returns me the same A.C for B.C. Those two are
> obviously not the same and the condition doesn't hold. This happens
> because the matchedByID map is constructed on the object IDs, and my model
> treats the names as IDs. It is incorrect in a sense that there are two C
> objects of the same ID, but we have no problems with this for now. So can
> anyone please suggest is there a way to match it not just by IDs? Can this
> mechanism be overridden?
>
> Vitaly


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: Child comparison problem [message #535102 is a reply to message #535057] Fri, 21 May 2010 09:52 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Thanks a lot, Cédric!

Adding the options did the job:) I have checked it quickly by adding them in getOption(...) method, but this is obviously a hack. Where is the correct place to set options in the engine? I believe this is the last question:) Thanks

Vitaly
Re: Child comparison problem [message #535137 is a reply to message #535102] Fri, 21 May 2010 12:22 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Good :)

you're right, the getOption is not the best place, I introduced the

org.eclipse.emf.compare.match.engine.GenericMatchEngine.upda teSettings(MatchSettings,
Map<String, Object>)

method lately which is responsible for updating the "MatchSetting" object
based on the options maps, you can override this method to force some
options.



Vitaly Savickas wrote:

> Thanks a lot, Cédric!
>
> Adding the options did the job:) I have checked it quickly by adding them
> in getOption(...) method, but this is obviously a hack. Where is the
> correct place to set options in the engine? I believe this is the last
> question:) Thanks
>
> Vitaly


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: Child comparison problem [message #535183 is a reply to message #535137] Fri, 21 May 2010 13:44 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Yes, I've seen it in the docs but don't see it in the class. Maybe I am using not the latest version of compare. Anyway, thanks for help!

Vitaly
Re: Child comparison problem [message #622917 is a reply to message #534728] Thu, 20 May 2010 10:09 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Thanks Laurent.

Yes, I understand that isSimilar(...) must be responsible for that, but this is also the reason I am confused about this problem: when I debugged the whole compare process of two models isSimilar(...) was always true. I've also noticed that it didn't even get called on the B.C, but instead got called several times for A.C. I have a slight guess that it makes an assumption on the list of objects matched by their names and after C has matched it is never looked at again, but I'm not familiar with the algorithm so sorry if I'm wrong. Any ideas on why is it behaving this way?

Vitaly
Re: Child comparison problem [message #622918 is a reply to message #622917] Thu, 20 May 2010 16:34 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Vitaly Savickas wrote on Thu, 20 May 2010 06:09
> Thanks Laurent.
>
> Yes, I understand that isSimilar(...) must be responsible for that, but this is also the reason I am confused about this problem: when I debugged the whole compare process of two models isSimilar(...) was always true. I've also noticed that it didn't even get called on the B.C. I have a slight guess that it makes an assumption on the list of objects matched by their names and after C has matched it is never looked at again, but I'm not familiar with the algorithm so sorry if I'm wrong. Any ideas on why is it behaving this way?
>
> Vitaly


I've investigated it further and revealed that isSimilar(...) is ignored for B.C because of this bit of code in the mapLists(...) method of GenericMatchEngine:

...
final StringBuilder obj1Key = new StringBuilder();
obj1Key.append(NameSimilarity.findName(obj1));
obj1Key.append(obj1.hashCode());
EObject obj2 = matchedByID.get(obj1Key.toString());
...
if (notFoundList1.contains(obj1) && notFoundList2.contains(obj2) && isSimilar(obj1, obj2)) {
...
}

in which matchedByID returns me the same A.C for B.C. Those two are obviously not the same and the condition doesn't hold. This happens because the matchedByID map is constructed on the object IDs, and my model treats the names as IDs. It is incorrect in a sense that there are two C objects of the same ID, but we have no problems with this for now. So can anyone please suggest is there a way to match it not just by IDs? Can this mechanism be overridden?

Vitaly
Re: Child comparison problem [message #622919 is a reply to message #622918] Fri, 21 May 2010 08:04 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi Vitaly,

If you want to ignore this ID attribute you should pass the corresponding
options (for intrinsic or XMI ID's:

Map options = new HashMap();
options.put(MatchOptions.OPTION_IGNORE_XMI_ID, Boolean.TRUE);
options.put(MatchOptions.OPTION_IGNORE_ID, Boolean.TRUE);


As a sidenote I fixed a regression about the root elements matching this
week, it would be safer for you to use the RC1 (or the CVS HEAD).

Cheers,

Cédric

Vitaly Savickas wrote:

> Vitaly Savickas wrote on Thu, 20 May 2010 06:09
>> Thanks Laurent.
>>
>> Yes, I understand that isSimilar(...) must be responsible for that, but
>> this is also the reason I am confused about this problem: when I debugged
>> the whole compare process of two models isSimilar(...) was always true.
>> I've also noticed that it didn't even get called on the B.C. I have a
>> slight guess that it makes an assumption on the list of objects matched
>> by their names and after C has matched it is never looked at again, but
>> I'm not familiar with the algorithm so sorry if I'm wrong. Any ideas on
>> why is it behaving this way?
>>
>> Vitaly
>
>
> I've investigated it further and revealed that isSimilar(...) is ignored
> for B.C because of this bit of code in the mapLists(...) method of
> GenericMatchEngine:
>
> ...
> final StringBuilder obj1Key = new StringBuilder();
> obj1Key.append(NameSimilarity.findName(obj1));
> obj1Key.append(obj1.hashCode());
> EObject obj2 = matchedByID.get(obj1Key.toString());
> ...
> if (notFoundList1.contains(obj1) && notFoundList2.contains(obj2) &&
> isSimilar(obj1, obj2)) { ...
> }
>
> in which matchedByID returns me the same A.C for B.C. Those two are
> obviously not the same and the condition doesn't hold. This happens
> because the matchedByID map is constructed on the object IDs, and my model
> treats the names as IDs. It is incorrect in a sense that there are two C
> objects of the same ID, but we have no problems with this for now. So can
> anyone please suggest is there a way to match it not just by IDs? Can this
> mechanism be overridden?
>
> Vitaly


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: Child comparison problem [message #622921 is a reply to message #535057] Fri, 21 May 2010 09:52 Go to previous messageGo to next message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Thanks a lot, Cédric!

Adding the options did the job:) I have checked it quickly by adding them in getOption(...) method, but this is obviously a hack. Where is the correct place to set options in the engine? I believe this is the last question:) Thanks

Vitaly
Re: Child comparison problem [message #622924 is a reply to message #535102] Fri, 21 May 2010 12:22 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Good :)

you're right, the getOption is not the best place, I introduced the

org.eclipse.emf.compare.match.engine.GenericMatchEngine.upda teSettings(MatchSettings,
Map<String, Object>)

method lately which is responsible for updating the "MatchSetting" object
based on the options maps, you can override this method to force some
options.



Vitaly Savickas wrote:

> Thanks a lot, Cédric!
>
> Adding the options did the job:) I have checked it quickly by adding them
> in getOption(...) method, but this is obviously a hack. Where is the
> correct place to set options in the engine? I believe this is the last
> question:) Thanks
>
> Vitaly


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: Child comparison problem [message #622925 is a reply to message #535137] Fri, 21 May 2010 13:44 Go to previous message
Vitaly Savickas is currently offline Vitaly SavickasFriend
Messages: 62
Registered: March 2010
Member
Yes, I've seen it in the docs but don't see it in the class. Maybe I am using not the latest version of compare. Anyway, thanks for help!

Vitaly
Previous Topic:Child comparison problem
Next Topic:[EMF Teneo] problems with integration of MySQL and EclipseLink in EMF Teneo
Goto Forum:
  


Current Time: Thu Mar 28 12:09:55 GMT 2024

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

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

Back to the top