Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » EMF Compare Bug 248442: EFeatureMap$Entry always changed
EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #135244] Thu, 23 April 2009 08:01 Go to next message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hi all,


we want to use EMF Compare for an EMF Model generated from a relatively
complicated XSD. The XSD may not be changed btw.
The generated EMF maps some features to EFeatureMap$Entry which
GenericDiffEngine is not able to handle correctly.

The problem is described very well in bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248442

Maybe Alexander doesn't need this any more, but we (large automobile
vendor) need the diff working urgently. So I think about contributing a
patch to EMF Compare.

Alexander describes the problem as follows:
> The problem seems to be that the checkAttributesUpdates method within
> GenericDiffService does only handle EAttributes of type EEnumLiteral
> explicitly, while comparing all other EAttributes by calling equals on
> their values. This does however not work for EAttributes of the above
> mentioned types, were all entries would have to be compared as lists
> instead (similar to as it is done for EReferences).

I thought about creating a third check*Updates() method in addition to
checkAttributesUpdates(current, match);
checkReferencesUpdates(current, match);
to care about EFeatureMap entries and call it from checkForDiffs().

But FeatureMaps are somewhat special - reflecting the semantics of the XSD
they're derived from:

Consider a XML fragment like this:
<persons>
<male name="Hector"/>
<female name="Anna"/>
<child name="Kevin"/>
<male name="Arnold"/>
</persons>

The FeatureMap "mixed" in the generated EMF class PersonsImpl would have 4
_ordered_ entries:
Feature "Male", value: the "Hector" named Male instance
Feature "Female", value: the "Anna" named Female instance
Feature "Child", value: the "Kevin" named Child instance
Feature "Male", value: the "Arnold" named Male instance

So how should the GenericDiffEngine handle this to support:
- detecting changes in each of the objects
- addition or removal of objects to that list
- re-order of elements in the list

I am somewhat lost about how to implement this and would be really really
happy about any kind of help. I would greatly appreciate any kind of hint
on how to implement this.



Thanks a lot in advance

Christian
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #135255 is a reply to message #135244] Thu, 23 April 2009 10:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Christian,

Note that in the case of a feature map, the other features that delegate
onto the feature map are derived, and changes to derived features really
shouldn't be recorded or taken into consideration. So in that sense,
only the change to the feature map itself matter and from that point of
view its effectively "just a list" of FeatureMap.Entry instances. Maybe
looking at how the Change model's ChangeRecorder deals with feature maps
might help shed some light...


Christian Muth wrote:
> Hi all,
>
>
> we want to use EMF Compare for an EMF Model generated from a
> relatively complicated XSD. The XSD may not be changed btw.
> The generated EMF maps some features to EFeatureMap$Entry which
> GenericDiffEngine is not able to handle correctly.
> The problem is described very well in bug report:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=248442
>
> Maybe Alexander doesn't need this any more, but we (large automobile
> vendor) need the diff working urgently. So I think about contributing
> a patch to EMF Compare.
>
> Alexander describes the problem as follows:
>> The problem seems to be that the checkAttributesUpdates method within
>> GenericDiffService does only handle EAttributes of type EEnumLiteral
>> explicitly, while comparing all other EAttributes by calling equals
>> on their values. This does however not work for EAttributes of the above
>> mentioned types, were all entries would have to be compared as lists
>> instead (similar to as it is done for EReferences).
>
> I thought about creating a third check*Updates() method in addition to
> checkAttributesUpdates(current, match);
> checkReferencesUpdates(current, match);
> to care about EFeatureMap entries and call it from checkForDiffs().
>
> But FeatureMaps are somewhat special - reflecting the semantics of the
> XSD they're derived from:
>
> Consider a XML fragment like this:
> <persons>
> <male name="Hector"/>
> <female name="Anna"/>
> <child name="Kevin"/>
> <male name="Arnold"/>
> </persons>
>
> The FeatureMap "mixed" in the generated EMF class PersonsImpl would
> have 4 _ordered_ entries:
> Feature "Male", value: the "Hector" named Male instance
> Feature "Female", value: the "Anna" named Female instance
> Feature "Child", value: the "Kevin" named Child instance
> Feature "Male", value: the "Arnold" named Male instance
>
> So how should the GenericDiffEngine handle this to support:
> - detecting changes in each of the objects
> - addition or removal of objects to that list
> - re-order of elements in the list
>
> I am somewhat lost about how to implement this and would be really
> really happy about any kind of help. I would greatly appreciate any
> kind of hint on how to implement this.
>
>
>
> Thanks a lot in advance
>
> Christian
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #135266 is a reply to message #135244] Thu, 23 April 2009 11:52 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.
--------------070908070102060601010108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Christian,

Actually, I already have written code to handle featuremap entries. I
just realized that somewhere along the history of the diff engine, I
have replaced the import of "FeatureMap.Entry" by an import for
"Map.Entry" ... thus rendering all "instanceof Entry" ineffective. I'll
try and see if I have recently started on the fixing of this and can't
really say when it will be ready.

As for the ordering ... EMF Compare doesn't actually detect changes on
the ordering of an attribute values. The code is partially implemented
for reference ordering change ("partially" since we don't take this
detection into account in the merging of other changes regarding
references values) and something of the sort should also be implemented
for attributes.

You can either file a bug for this (somewhat of a copy of bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=269152 would do), or
directly patch the code for this (reusing the idea of
GenericDiffEngine#checkReferenceOrderChange() would probably be
sufficiant)... or both :).

Laurent Goubet
Obeo

Christian Muth a
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #135279 is a reply to message #135266] Thu, 23 April 2009 13:06 Go to previous messageGo to next message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hi Laurent,


thanks for your fast response!
> Actually, I already have written code to handle featuremap entries. I
> just realized that somewhere along the history of the diff engine, I
> have replaced the import of "FeatureMap.Entry" by an import for
> "Map.Entry" ... thus rendering all "instanceof Entry" ineffective. I'll
> try and see if I have recently started on the fixing of this and can't
> really say when it will be ready.
Where could i have a look at this version you mentioned? Is it available
via CVS/SVN?

> As for the ordering ... EMF Compare doesn't actually detect changes on
> the ordering of an attribute values. The code is partially implemented
> for reference ordering change ("partially" since we don't take this
> detection into account in the merging of other changes regarding
> references values) and something of the sort should also be implemented
> for attributes.
> You can either file a bug for this (somewhat of a copy of bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269152 would do), or
> directly patch the code for this (reusing the idea of
> GenericDiffEngine#checkReferenceOrderChange() would probably be
> sufficiant)... or both :).
Okay, I'll have a look at this.


Thanks again!

Christian
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #135292 is a reply to message #135255] Thu, 23 April 2009 13:09 Go to previous messageGo to next message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hi Ed,


thanks for your response!
> Note that in the case of a feature map, the other features that delegate
> onto the feature map are derived, and changes to derived features really
> shouldn't be recorded or taken into consideration. So in that sense,
> only the change to the feature map itself matter and from that point of
> view its effectively "just a list" of FeatureMap.Entry instances. Maybe
> looking at how the Change model's ChangeRecorder deals with feature maps
> might help shed some light...
Okay, i'll have a look at ChangeRecorder. Laurent wrote that he already has
got some code that cares about FeatureMaps but not their ordering.
I'll investigate that over the weekend in more detail.


Thanks a lot.


Christian
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #135305 is a reply to message #135279] Fri, 24 April 2009 15:27 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050900080309010406000904
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Hi Christian,

Sorry for the delay, I was trying to understand why my previous code
wasn't working anymore. The import "FeatureMap.Entry" changed for
"Map.Entry" already dated back to july 2008 so the code has been there
for a long time... not working :p.

EMF Compare should now properly handle FeatureMap.Entries though it
doesn't detect changes in the ordering of attribute values. I'll let you
comment on bug 248442 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248442 ) for any
additional issue you encounter on this.

Laurent Goubet
Obeo

Christian Muth a
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #620844 is a reply to message #135244] Thu, 23 April 2009 10:21 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Christian,

Note that in the case of a feature map, the other features that delegate
onto the feature map are derived, and changes to derived features really
shouldn't be recorded or taken into consideration. So in that sense,
only the change to the feature map itself matter and from that point of
view its effectively "just a list" of FeatureMap.Entry instances. Maybe
looking at how the Change model's ChangeRecorder deals with feature maps
might help shed some light...


Christian Muth wrote:
> Hi all,
>
>
> we want to use EMF Compare for an EMF Model generated from a
> relatively complicated XSD. The XSD may not be changed btw.
> The generated EMF maps some features to EFeatureMap$Entry which
> GenericDiffEngine is not able to handle correctly.
> The problem is described very well in bug report:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=248442
>
> Maybe Alexander doesn't need this any more, but we (large automobile
> vendor) need the diff working urgently. So I think about contributing
> a patch to EMF Compare.
>
> Alexander describes the problem as follows:
>> The problem seems to be that the checkAttributesUpdates method within
>> GenericDiffService does only handle EAttributes of type EEnumLiteral
>> explicitly, while comparing all other EAttributes by calling equals
>> on their values. This does however not work for EAttributes of the above
>> mentioned types, were all entries would have to be compared as lists
>> instead (similar to as it is done for EReferences).
>
> I thought about creating a third check*Updates() method in addition to
> checkAttributesUpdates(current, match);
> checkReferencesUpdates(current, match);
> to care about EFeatureMap entries and call it from checkForDiffs().
>
> But FeatureMaps are somewhat special - reflecting the semantics of the
> XSD they're derived from:
>
> Consider a XML fragment like this:
> <persons>
> <male name="Hector"/>
> <female name="Anna"/>
> <child name="Kevin"/>
> <male name="Arnold"/>
> </persons>
>
> The FeatureMap "mixed" in the generated EMF class PersonsImpl would
> have 4 _ordered_ entries:
> Feature "Male", value: the "Hector" named Male instance
> Feature "Female", value: the "Anna" named Female instance
> Feature "Child", value: the "Kevin" named Child instance
> Feature "Male", value: the "Arnold" named Male instance
>
> So how should the GenericDiffEngine handle this to support:
> - detecting changes in each of the objects
> - addition or removal of objects to that list
> - re-order of elements in the list
>
> I am somewhat lost about how to implement this and would be really
> really happy about any kind of help. I would greatly appreciate any
> kind of hint on how to implement this.
>
>
>
> Thanks a lot in advance
>
> Christian
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #620845 is a reply to message #135244] Thu, 23 April 2009 11:52 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070908070102060601010108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Christian,

Actually, I already have written code to handle featuremap entries. I
just realized that somewhere along the history of the diff engine, I
have replaced the import of "FeatureMap.Entry" by an import for
"Map.Entry" ... thus rendering all "instanceof Entry" ineffective. I'll
try and see if I have recently started on the fixing of this and can't
really say when it will be ready.

As for the ordering ... EMF Compare doesn't actually detect changes on
the ordering of an attribute values. The code is partially implemented
for reference ordering change ("partially" since we don't take this
detection into account in the merging of other changes regarding
references values) and something of the sort should also be implemented
for attributes.

You can either file a bug for this (somewhat of a copy of bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=269152 would do), or
directly patch the code for this (reusing the idea of
GenericDiffEngine#checkReferenceOrderChange() would probably be
sufficiant)... or both :).

Laurent Goubet
Obeo

Christian Muth a
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #620867 is a reply to message #135266] Thu, 23 April 2009 13:06 Go to previous message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hi Laurent,


thanks for your fast response!
> Actually, I already have written code to handle featuremap entries. I
> just realized that somewhere along the history of the diff engine, I
> have replaced the import of "FeatureMap.Entry" by an import for
> "Map.Entry" ... thus rendering all "instanceof Entry" ineffective. I'll
> try and see if I have recently started on the fixing of this and can't
> really say when it will be ready.
Where could i have a look at this version you mentioned? Is it available
via CVS/SVN?

> As for the ordering ... EMF Compare doesn't actually detect changes on
> the ordering of an attribute values. The code is partially implemented
> for reference ordering change ("partially" since we don't take this
> detection into account in the merging of other changes regarding
> references values) and something of the sort should also be implemented
> for attributes.
> You can either file a bug for this (somewhat of a copy of bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269152 would do), or
> directly patch the code for this (reusing the idea of
> GenericDiffEngine#checkReferenceOrderChange() would probably be
> sufficiant)... or both :).
Okay, I'll have a look at this.


Thanks again!

Christian
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #620868 is a reply to message #135255] Thu, 23 April 2009 13:09 Go to previous message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hi Ed,


thanks for your response!
> Note that in the case of a feature map, the other features that delegate
> onto the feature map are derived, and changes to derived features really
> shouldn't be recorded or taken into consideration. So in that sense,
> only the change to the feature map itself matter and from that point of
> view its effectively "just a list" of FeatureMap.Entry instances. Maybe
> looking at how the Change model's ChangeRecorder deals with feature maps
> might help shed some light...
Okay, i'll have a look at ChangeRecorder. Laurent wrote that he already has
got some code that cares about FeatureMaps but not their ordering.
I'll investigate that over the weekend in more detail.


Thanks a lot.


Christian
Re: EMF Compare Bug 248442: EFeatureMap$Entry always changed [message #620869 is a reply to message #135279] Fri, 24 April 2009 15:27 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050900080309010406000904
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Hi Christian,

Sorry for the delay, I was trying to understand why my previous code
wasn't working anymore. The import "FeatureMap.Entry" changed for
"Map.Entry" already dated back to july 2008 so the code has been there
for a long time... not working :p.

EMF Compare should now properly handle FeatureMap.Entries though it
doesn't detect changes in the ordering of attribute values. I'll let you
comment on bug 248442 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248442 ) for any
additional issue you encounter on this.

Laurent Goubet
Obeo

Christian Muth a
Previous Topic:EMF Compare Bug 248442: EFeatureMap$Entry always changed
Next Topic:[Announce] EMFT COMPARE 0.9.0 I200904241122 is available
Goto Forum:
  


Current Time: Fri Mar 29 15:22:38 GMT 2024

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

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

Back to the top