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 |
Christian Muth 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 |
Ed Merks 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 |
|
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 #135305 is a reply to message #135279] |
Fri, 24 April 2009 15:27 |
|
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 |
Ed Merks 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 |
|
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 #620869 is a reply to message #135279] |
Fri, 24 April 2009 15:27 |
|
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
|
|
|
Goto Forum:
Current Time: Fri Mar 29 15:22:38 GMT 2024
Powered by FUDForum. Page generated in 0.03182 seconds
|