Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF Compare] Duplicate move detection
[EMF Compare] Duplicate move detection [message #531780] Thu, 06 May 2010 07:37 Go to next message
Patrick Konemann is currently offline Patrick KonemannFriend
Messages: 116
Registered: July 2009
Senior Member
In one of my comparisons I moved one element but EMF Compare produced two changes: A MoveModelElement (regular move) and a UpdateContainmentFeature (containment change), and both contain the very same properties!
Example scenario and proposed fix below.


Scenario:

Changing an association between two UML classes from unidirectional to directional.
Technically speaking: The first listing is the model with the unidirectional association, the second listing the model with the directional association.

<Class> A
<Class> B
- (feature ownedAttribute): <Property> dst : A
<Association> A_src_dst
- (feature ownedEnds): <Property> src : B

<Class> A
- (feature ownedAttribute): <Property> src : B
<Class> B
- (feature ownedAttribute): <Property> dst : A
<Association> A_src_dst

The two changes that EMF Compare detects are:
- <Property> src : X has been moved from <Class> Y to <Association> A_src_dst
- Containment reference has been changed from ownedAttribute to ownedEnd

As I understand it, there is a bug for the detection of containment reference changes: they should only be detected if it is not already a move. In other words, the containment reference changes should only be created if the container differs.

I checked the generic diff engine and saw that this check is done for Match3Elements but not for Match2Elements.
So I guess we just need to adjust the generic diff engine as follows (just one line added; untested):

protected void checkContainmentUpdate(DiffGroup current, Match2Elements matchElement) {
final EObject leftElement = matchElement.getLeftElement();
final EObject rightElement = matchElement.getRightElement();
if (leftElement.eContainmentFeature() != null && rightElement.eContainmentFeature() != null) {
if (!leftElement.eContainmentFeature().getName().equals(
rightElement.eContainmentFeature().getName())
&& getMatchedEObject(leftElement.eContainer()).equals(rightElem ent.eContainer() // this line is new
) {
createUpdateContainmentOperation(current, leftElement, rightElement);
}
}
}

Best regards
Patrick
Re: [EMF Compare] Duplicate move detection [message #531793 is a reply to message #531780] Thu, 06 May 2010 08:32 Go to previous messageGo to next message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi Patrick,

Thanks :) please report a bug including, if possible, the incriminated
models and we'll fix this issue for the next release :)

Cédric

Patrick Könemann wrote:

> In one of my comparisons I moved one element but EMF Compare produced two
> changes: A MoveModelElement (regular move) and a UpdateContainmentFeature
> (containment change), and both contain the very same properties! Example
> scenario and proposed fix below.
>
>
> Scenario:
>
> Changing an association between two UML classes from unidirectional to
> directional. Technically speaking: The first listing is the model with the
> unidirectional association, the second listing the model with the
> directional association.
>
> <Class> A
> <Class> B
> - (feature ownedAttribute): <Property> dst : A
> <Association> A_src_dst
> - (feature ownedEnds): <Property> src : B
>
> <Class> A
> - (feature ownedAttribute): <Property> src : B
> <Class> B
> - (feature ownedAttribute): <Property> dst : A
> <Association> A_src_dst
>
> The two changes that EMF Compare detects are:
> - <Property> src : X has been moved from <Class> Y to <Association>
> A_src_dst - Containment reference has been changed from ownedAttribute to
> ownedEnd
>
> As I understand it, there is a bug for the detection of containment
> reference changes: they should only be detected if it is not already a
> move. In other words, the containment reference changes should only be
> created if the container differs.
>
> I checked the generic diff engine and saw that this check is done for
> Match3Elements but not for Match2Elements. So I guess we just need to
> adjust the generic diff engine as follows (just one line added; untested):
>
> protected void checkContainmentUpdate(DiffGroup current, Match2Elements
> matchElement) { final EObject leftElement = matchElement.getLeftElement();
> final EObject rightElement = matchElement.getRightElement();
> if (leftElement.eContainmentFeature() != null &&
> rightElement.eContainmentFeature() != null) { if
> (!leftElement.eContainmentFeature().getName().equals(
> rightElement.eContainmentFeature().getName()) &&
>
getMatchedEObject(leftElement.eContainer()).equals(rightElem ent.eContainer()
> // this line is new ) { createUpdateContainmentOperation(current,
> leftElement, rightElement); }
> }
> }
>
> Best regards
> Patrick


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: [EMF Compare] Duplicate move detection [message #531874 is a reply to message #531793] Thu, 06 May 2010 13:09 Go to previous message
Patrick Konemann is currently offline Patrick KonemannFriend
Messages: 116
Registered: July 2009
Senior Member
Sure: https://bugs.eclipse.org/bugs/show_bug.cgi?id=311872

On 06-05-2010 10:33, Cédric Brun wrote:
> Hi Patrick,
>
> Thanks :) please report a bug including, if possible, the incriminated
> models and we'll fix this issue for the next release :)
>
> Cédric
>
> Patrick Könemann wrote:
>
>> In one of my comparisons I moved one element but EMF Compare produced two
>> changes: A MoveModelElement (regular move) and a UpdateContainmentFeature
>> (containment change), and both contain the very same properties! Example
>> scenario and proposed fix below.
>>
>>
>> Scenario:
>>
>> Changing an association between two UML classes from unidirectional to
>> directional. Technically speaking: The first listing is the model with the
>> unidirectional association, the second listing the model with the
>> directional association.
>>
>> <Class> A
>> <Class> B
>> - (feature ownedAttribute):<Property> dst : A
>> <Association> A_src_dst
>> - (feature ownedEnds):<Property> src : B
>>
>> <Class> A
>> - (feature ownedAttribute):<Property> src : B
>> <Class> B
>> - (feature ownedAttribute):<Property> dst : A
>> <Association> A_src_dst
>>
>> The two changes that EMF Compare detects are:
>> -<Property> src : X has been moved from<Class> Y to<Association>
>> A_src_dst - Containment reference has been changed from ownedAttribute to
>> ownedEnd
>>
>> As I understand it, there is a bug for the detection of containment
>> reference changes: they should only be detected if it is not already a
>> move. In other words, the containment reference changes should only be
>> created if the container differs.
>>
>> I checked the generic diff engine and saw that this check is done for
>> Match3Elements but not for Match2Elements. So I guess we just need to
>> adjust the generic diff engine as follows (just one line added; untested):
>>
>> protected void checkContainmentUpdate(DiffGroup current, Match2Elements
>> matchElement) { final EObject leftElement = matchElement.getLeftElement();
>> final EObject rightElement = matchElement.getRightElement();
>> if (leftElement.eContainmentFeature() != null&&
>> rightElement.eContainmentFeature() != null) { if
>> (!leftElement.eContainmentFeature().getName().equals(
>> rightElement.eContainmentFeature().getName())&&
>>
> getMatchedEObject(leftElement.eContainer()).equals(rightElem ent.eContainer()
>> // this line is new ) { createUpdateContainmentOperation(current,
>> leftElement, rightElement); }
>> }
>> }
>>
>> Best regards
>> Patrick
>
Re: [EMF Compare] Duplicate move detection [message #622833 is a reply to message #531780] Thu, 06 May 2010 08:33 Go to previous message
Cedric Brun is currently offline Cedric BrunFriend
Messages: 431
Registered: July 2009
Senior Member
Hi Patrick,

Thanks :) please report a bug including, if possible, the incriminated
models and we'll fix this issue for the next release :)

Cédric

Patrick Könemann wrote:

> In one of my comparisons I moved one element but EMF Compare produced two
> changes: A MoveModelElement (regular move) and a UpdateContainmentFeature
> (containment change), and both contain the very same properties! Example
> scenario and proposed fix below.
>
>
> Scenario:
>
> Changing an association between two UML classes from unidirectional to
> directional. Technically speaking: The first listing is the model with the
> unidirectional association, the second listing the model with the
> directional association.
>
> <Class> A
> <Class> B
> - (feature ownedAttribute): <Property> dst : A
> <Association> A_src_dst
> - (feature ownedEnds): <Property> src : B
>
> <Class> A
> - (feature ownedAttribute): <Property> src : B
> <Class> B
> - (feature ownedAttribute): <Property> dst : A
> <Association> A_src_dst
>
> The two changes that EMF Compare detects are:
> - <Property> src : X has been moved from <Class> Y to <Association>
> A_src_dst - Containment reference has been changed from ownedAttribute to
> ownedEnd
>
> As I understand it, there is a bug for the detection of containment
> reference changes: they should only be detected if it is not already a
> move. In other words, the containment reference changes should only be
> created if the container differs.
>
> I checked the generic diff engine and saw that this check is done for
> Match3Elements but not for Match2Elements. So I guess we just need to
> adjust the generic diff engine as follows (just one line added; untested):
>
> protected void checkContainmentUpdate(DiffGroup current, Match2Elements
> matchElement) { final EObject leftElement = matchElement.getLeftElement();
> final EObject rightElement = matchElement.getRightElement();
> if (leftElement.eContainmentFeature() != null &&
> rightElement.eContainmentFeature() != null) { if
> (!leftElement.eContainmentFeature().getName().equals(
> rightElement.eContainmentFeature().getName()) &&
>
getMatchedEObject(leftElement.eContainer()).equals(rightElem ent.eContainer()
> // this line is new ) { createUpdateContainmentOperation(current,
> leftElement, rightElement); }
> }
> }
>
> Best regards
> Patrick


http://cedric.brun.io news and articles on eclipse and eclipse modeling.
Re: [EMF Compare] Duplicate move detection [message #622835 is a reply to message #622833] Thu, 06 May 2010 13:09 Go to previous message
Patrick Konemann is currently offline Patrick KonemannFriend
Messages: 116
Registered: July 2009
Senior Member
Sure: https://bugs.eclipse.org/bugs/show_bug.cgi?id=311872

On 06-05-2010 10:33, Cédric Brun wrote:
> Hi Patrick,
>
> Thanks :) please report a bug including, if possible, the incriminated
> models and we'll fix this issue for the next release :)
>
> Cédric
>
> Patrick Könemann wrote:
>
>> In one of my comparisons I moved one element but EMF Compare produced two
>> changes: A MoveModelElement (regular move) and a UpdateContainmentFeature
>> (containment change), and both contain the very same properties! Example
>> scenario and proposed fix below.
>>
>>
>> Scenario:
>>
>> Changing an association between two UML classes from unidirectional to
>> directional. Technically speaking: The first listing is the model with the
>> unidirectional association, the second listing the model with the
>> directional association.
>>
>> <Class> A
>> <Class> B
>> - (feature ownedAttribute):<Property> dst : A
>> <Association> A_src_dst
>> - (feature ownedEnds):<Property> src : B
>>
>> <Class> A
>> - (feature ownedAttribute):<Property> src : B
>> <Class> B
>> - (feature ownedAttribute):<Property> dst : A
>> <Association> A_src_dst
>>
>> The two changes that EMF Compare detects are:
>> -<Property> src : X has been moved from<Class> Y to<Association>
>> A_src_dst - Containment reference has been changed from ownedAttribute to
>> ownedEnd
>>
>> As I understand it, there is a bug for the detection of containment
>> reference changes: they should only be detected if it is not already a
>> move. In other words, the containment reference changes should only be
>> created if the container differs.
>>
>> I checked the generic diff engine and saw that this check is done for
>> Match3Elements but not for Match2Elements. So I guess we just need to
>> adjust the generic diff engine as follows (just one line added; untested):
>>
>> protected void checkContainmentUpdate(DiffGroup current, Match2Elements
>> matchElement) { final EObject leftElement = matchElement.getLeftElement();
>> final EObject rightElement = matchElement.getRightElement();
>> if (leftElement.eContainmentFeature() != null&&
>> rightElement.eContainmentFeature() != null) { if
>> (!leftElement.eContainmentFeature().getName().equals(
>> rightElement.eContainmentFeature().getName())&&
>>
> getMatchedEObject(leftElement.eContainer()).equals(rightElem ent.eContainer()
>> // this line is new ) { createUpdateContainmentOperation(current,
>> leftElement, rightElement); }
>> }
>> }
>>
>> Best regards
>> Patrick
>
Previous Topic:[EMF Compare] Duplicate move detection
Next Topic:EMF object serialization into xml
Goto Forum:
  


Current Time: Fri Mar 29 10:28:14 GMT 2024

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

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

Back to the top