Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeChange
Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeChange [message #1696735] Thu, 28 May 2015 09:46 Go to next message
Mark Hoffmann is currently offline Mark HoffmannFriend
Messages: 113
Registered: July 2009
Location: Jena
Senior Member
Hello,

I discovered some thing I dont understand. I use EMF Compare in an JEE environment.
I have an object e.g. Person that has a containing object Address. If I change the street attibute of the Address instance and compare the two person instances after the street change, in my JavaSE Unit Tests the street change occurs as one AttributeChange of kind CHANGE. The same code integrated in the JEE Server delivers for the same change for the street two ReferenceChanges Person.address 1. ADD Address with new new street, 2. DELETE old Address with old street.

Both Person instance come from different sources and have different ResourceSets. I created the same situation in my JUnit tests. But its is still an AttributeChange in JUnit and two ReferenceChanges in the JEE Server.

In JEE the one instance is serialized from an XML using a temporary file resource, which was loaded from an InputStream. The second instance was loaded using MongoEMF.
In the unit test I just load two instances from two different XML files.

UPDATE: Now I got two ReferenceChanges in my JUnit test. I loaded one instance from a XML file. The second instance was created using EcoreUtil#copy. After that I changed the street attribute and attached the object to a new Resource. So loading two different Person files with two different streets a compare leads to an AttributeChange. Loading one file, copy it and change the Street attribute and compare the two objects leads to two ReferenceChanges.


My question is, what causes the creation of the ReferenceChanges instead of AttributeChanges? What is the difference? Can anybody point me to the right direction?

Thanks,
Mark

UPDATE: I got not two ReferenceChanges in my JUnit test. I loaded one instance from a XML file. The second instance was created using EcoreUtil#copy. After that I changed the street attribute and attached the object to a new Resource.

[Updated on: Thu, 28 May 2015 09:56]

Report message to a moderator

Re: Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeCha [message #1696774 is a reply to message #1696735] Thu, 28 May 2015 13:51 Go to previous messageGo to next message
Axel RICHARD is currently offline Axel RICHARDFriend
Messages: 35
Registered: September 2010
Location: France
Member
Hi,

You will find the answers to your questions in the developer guide : https://www.eclipse.org/emf/compare/documentation/latest/developer/developer-guide.html

"...ReferenceChange differences will be detected for every value of a reference for which we detect a change. Either the value was added, deleted, or moved (within the reference or between distinct references). AttributeChange differences are the same, but for attributes instead of references."

Regards,


Axel Richard
Obeo
Re: Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeCha [message #1696779 is a reply to message #1696774] Thu, 28 May 2015 14:13 Go to previous messageGo to next message
Mark Hoffmann is currently offline Mark HoffmannFriend
Messages: 113
Registered: July 2009
Location: Jena
Senior Member
Hi Richard,

thank you for the answer. I have read this part.

Unfortunately I still dont understand why a change on an attribute causes sometimes AttributeChanges and sometimes ReferenceChanges.

If I load two objects from two several files with differences in these attribute and I compare them, I get an AttributeChange.

If I just load one file, copy it e.g. with EcoreUtil#copy, then change the attribute in the copy, attach it to a Resource and compare it then, I get two ReferenceChanges.

From the point of content, both use case are identical, but the result is different.

Mark

Re: Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeCha [message #1697631 is a reply to message #1696779] Fri, 05 June 2015 13:39 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1858
Registered: July 2009
Senior Member
Mark,

Without the comparison model, I can't say for sure. But I am pretty positive what you get is the following :
- use case 1 (comparing two copies of a file with a modified attribute in them)
=> AttributeChange "value of attribute x has changed to n"
- use case 2 (comparing an object with a copy of itself, with a difference in one of the attributes)
=> ReferenceChange "object x has been deleted"
=> ReferenceChange "object x has been added"

i.e. your objects are not matched together in the second use case. The most likely reason is that the only attribute they have is the street, and you changed it so much it can no longer be seen as being the same object. Another possibility is that you're using identifiers, and that identifier changed between the two copies (it is not copied along when using EcoreUtil#copy if it is an xmi:id).

Basically : look at your two copies and see if they can actually be seen as the same object by EMF Compare. Then, we'll see an attribute change. But if we see them as two different objects, we'll just tell you that one of the two has been deleted and the other added. You'll have to take a look at the matching phase of EMF Compare to determine why we're not matching them if one of the two options I outlined above isn't the right one. see org.eclipse.emf.compare.EMFCompare.compare(IComparisonScope, Monitor) at line 209 where we call the Match engine on your objects.

Regards,

Laurent Goubet
Obeo

[Updated on: Fri, 05 June 2015 13:39]

Report message to a moderator

Re: Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeCha [message #1707743 is a reply to message #1696735] Wed, 09 September 2015 05:18 Go to previous messageGo to next message
Vikhyat Prabhu is currently offline Vikhyat PrabhuFriend
Messages: 6
Registered: September 2015
Junior Member
Hi,
I am facing a similar problem. I am comparing a file with its copy with the only change being a new attribute(reference to a child node) is set at the containment object(root of the file).
Example structure of my files
File1:
<container>
<graph/>
<points/>
<points/>
<points/>
</container>

File 2:
<container startingPoint="//@points.1">
<graph/>
<points/>
<points/>
<points/>
</container>


With this lot of reference changes are detected by EMF Compare. I want to ignore these changes. Is there a way to ignore these reference changes caused by change to the root container ?

[Updated on: Wed, 09 September 2015 19:27]

Report message to a moderator

Re: Attribute changes in containment object result in ReferenceChange, but sometimes in AttributeCha [message #1708393 is a reply to message #1707743] Wed, 16 September 2015 08:43 Go to previous message
Philip Langer is currently offline Philip LangerFriend
Messages: 84
Registered: March 2015
Location: Vienna, Austria
Member

Hi Vikhyat,

Quote:
With this lot of reference changes are detected by EMF Compare.


I assume, the reason is that the <point/> elements are not matched, so EMF Compare considers them as being deleted and added. With the default matcher, the situation will be better, when you have "more distinctive" attribute values, such as names of points.

Quote:
Is there a way to ignore these reference changes caused by change to the root container ?


Where do you want to ignore them? If you only want to hide them in the comparison UI, you could for instance install a filter (extension point org.eclipse.emf.compare.rcp.ui.filters). If you also want to get rid of them in the comparison model, you could also install a postprocessor that removes them from the comparison model (extension point org.eclipse.emf.compare.rcp.postProcessor). But keep in mind that this will affect the result when you merge differences (that is, the reference changes you remove will of course not be merged later e.g. when the user hits "Copy all left to right", etc.).

Best wishes,

Philip


--
Philip Langer

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
Previous Topic:Manipulating the EMF Compare Editor
Next Topic:[EMF Compare] Extension Points for configuring phases not working
Goto Forum:
  


Current Time: Sun Sep 23 19:34:52 GMT 2018

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

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

Back to the top