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 |
Mark Hoffmann 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 #1696779 is a reply to message #1696774] |
Thu, 28 May 2015 14:13 |
Mark Hoffmann 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 |
|
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 |
Vikhyat Prabhu 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 |
|
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/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:04:12 GMT 2024
Powered by FUDForum. Page generated in 0.24600 seconds
|