Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF Compare] False positives on multivalued EReferences with containment=false
[EMF Compare] False positives on multivalued EReferences with containment=false [message #123636] Thu, 29 May 2008 15:53 Go to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi!

I've used EMF Compare with some models of mine, receiving some false
positives (sometime too much false positives). Those occur only in
multivalued EReferences that are apparently equal (referenced values
where equal). The only different thing from other ERefereces of the same
metamodel I've noticed is having no EOpposite and containment=false.

Take a look at these two models that generate a false positive (using
UMLX's QVT Core metamodel):


########### Model 1 #############

<?xml version="1.0" encoding="ASCII"?>
<eqvtbase:Transformation xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase" xmi:id="ast0"
name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
<modelParameter xmi:id="ast8" name="middle">
<usedPackage
href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
</modelParameter>
</eqvtbase:Transformation>

########### Model 2 #############

<?xml version="1.0" encoding="ASCII"?>
<eqvtbase:Transformation xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
<modelParameter xmi:id="ast8" name="middle">
<usedPackage
href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
</modelParameter>
</eqvtbase:Transformation>

####################################

- The only differences' I've introduced is the nsURI of the root node.

EMF Compare shows correctly the changes on the nsURI, but also changes
on "usedPackage" EReference, indicating that
" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / " has been
added on the first model, and deleted in the second one.

I've been digging a little bit in the source code and noticed what's
going on.

- Root node is marked as not equal (similarity = 0.6....)
- Typed model node is marked as equal (similarity = 1.0)

These four nodes are properly added to
"GenericDiffEngine::eObjectToMatch" hashMap.

The problem appears in "GenericDiffEngine::computeAddedReferences" and
"GenericDiffEngine::computeDeletedReferences", while trying to retrieve
from the map the matchModel of
" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ", which
doesn't actually exist in "eObjectToMatch" (what makes sense, since that
reference wasn't matched during first matching phase).


So I guess there are two solutions:

- Add these referenced resources to "eObjectToMatch"
- Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
("GenericDiffEngine::createNonConflictingReferencesUpdate" method)


I'm sorry if I haven't been clear. If necessary, I'll send you the
example models and metamodel.


Best regards,
Víctor.
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #124027 is a reply to message #123636] Fri, 30 May 2008 07:43 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080104060404080102060603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

We already have some bugs on references resolving, namely bugs #199877 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 ) and #229663 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).

If the issue you encounter doesn't fit in those, could you create a new
bug report with example models to reproduce this?

Thanks!

Laurent Goubet
Obeo

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #124847 is a reply to message #124027] Mon, 02 June 2008 10:45 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Laurent,

these bugs seems somehow related with what I've detected: proxy
resolution and broken references. The example I posted seems to match
both of those cases. However, I've got also some invalid diffs over
references to elements on the same model. As I have said, these
multivalued refences seemed equal when I take a look at the XMI, so
there most probable reason would problems during proxy resolution.

Curiously enough, these false triggering only appears if there is at
least 1 real difference in the model. If the models are completely
equal, no false differences are shown.

I have a model with one only real difference that actually returns like
45 false differences, all related with this problem. Unfortunately, I
cant provide it since its property of the company I work for. All I have
is this false triggering over some UMLX QVT Core instances. I'll try to
get these with some public metamodels so I can send them to you.

Cheers,
Víctor.

laurent Goubet escribió:
> Hi,
>
> We already have some bugs on references resolving, namely bugs #199877 (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 ) and #229663 (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>
> If the issue you encounter doesn't fit in those, could you create a new
> bug report with example models to reproduce this?
>
> Thanks!
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Hi!
>>
>> I've used EMF Compare with some models of mine, receiving some false
>> positives (sometime too much false positives). Those occur only in
>> multivalued EReferences that are apparently equal (referenced values
>> where equal). The only different thing from other ERefereces of the
>> same metamodel I've noticed is having no EOpposite and containment=false.
>>
>> Take a look at these two models that generate a false positive (using
>> UMLX's QVT Core metamodel):
>>
>>
>> ########### Model 1 #############
>>
>> <?xml version="1.0" encoding="ASCII"?>
>> <eqvtbase:Transformation xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>> <modelParameter xmi:id="ast8" name="middle">
>> <usedPackage
>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>> </modelParameter>
>> </eqvtbase:Transformation>
>>
>> ########### Model 2 #############
>>
>> <?xml version="1.0" encoding="ASCII"?>
>> <eqvtbase:Transformation xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>> <modelParameter xmi:id="ast8" name="middle">
>> <usedPackage
>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>> </modelParameter>
>> </eqvtbase:Transformation>
>>
>> ####################################
>>
>> - The only differences' I've introduced is the nsURI of the root node.
>>
>> EMF Compare shows correctly the changes on the nsURI, but also changes
>> on "usedPackage" EReference, indicating that
>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / " has been
>> added on the first model, and deleted in the second one.
>>
>> I've been digging a little bit in the source code and noticed what's
>> going on.
>>
>> - Root node is marked as not equal (similarity = 0.6....)
>> - Typed model node is marked as equal (similarity = 1.0)
>>
>> These four nodes are properly added to
>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>
>> The problem appears in "GenericDiffEngine::computeAddedReferences" and
>> "GenericDiffEngine::computeDeletedReferences", while trying to
>> retrieve from the map the matchModel of
>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ", which
>> doesn't actually exist in "eObjectToMatch" (what makes sense, since
>> that reference wasn't matched during first matching phase).
>>
>>
>> So I guess there are two solutions:
>>
>> - Add these referenced resources to "eObjectToMatch"
>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>
>>
>> I'm sorry if I haven't been clear. If necessary, I'll send you the
>> example models and metamodel.
>>
>>
>> Best regards,
>> Víctor.
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #124872 is a reply to message #124847] Mon, 02 June 2008 11:38 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010006020507080801070700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125048 is a reply to message #124872] Tue, 03 June 2008 15:26 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Laurent,

after 2 days searching, I found the source of the problem for these
false positives. And it's not about containment. It's about the
"derived" attribute of an EAttribute/EReference. In my case, I had a
derived EReference (it shouldn't be that way, actually), which was also
container. Any model element contained by this "derived" EReference was
ignored by the engine during the matching. Is this a correct behaviour?
Should I raise a bugzilla?

Thanks!

Víctor.

laurent Goubet escribió:
> Víctor,
>
> Yes, if there isn't any real differences, the two files are exactly the
> same and compare won't go through the trouble of finding other
> comparators (such as EMF Compare) to try and find what has been changed.
>
> Having example models would indeed be the best for us to understand the
> actual issue. I can easily understand that having 1 difference
> triggerring 45 false positives is unexploitable.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> these bugs seems somehow related with what I've detected: proxy
>> resolution and broken references. The example I posted seems to match
>> both of those cases. However, I've got also some invalid diffs over
>> references to elements on the same model. As I have said, these
>> multivalued refences seemed equal when I take a look at the XMI, so
>> there most probable reason would problems during proxy resolution.
>>
>> Curiously enough, these false triggering only appears if there is at
>> least 1 real difference in the model. If the models are completely
>> equal, no false differences are shown.
>>
>> I have a model with one only real difference that actually returns
>> like 45 false differences, all related with this problem.
>> Unfortunately, I cant provide it since its property of the company I
>> work for. All I have is this false triggering over some UMLX QVT Core
>> instances. I'll try to get these with some public metamodels so I can
>> send them to you.
>>
>> Cheers,
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Hi,
>>>
>>> We already have some bugs on references resolving, namely bugs
>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 ) and
>>> #229663 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>
>>> If the issue you encounter doesn't fit in those, could you create a
>>> new bug report with example models to reproduce this?
>>>
>>> Thanks!
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Hi!
>>>>
>>>> I've used EMF Compare with some models of mine, receiving some false
>>>> positives (sometime too much false positives). Those occur only in
>>>> multivalued EReferences that are apparently equal (referenced values
>>>> where equal). The only different thing from other ERefereces of the
>>>> same metamodel I've noticed is having no EOpposite and
>>>> containment=false.
>>>>
>>>> Take a look at these two models that generate a false positive
>>>> (using UMLX's QVT Core metamodel):
>>>>
>>>>
>>>> ########### Model 1 #############
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>> <modelParameter xmi:id="ast8" name="middle">
>>>> <usedPackage
>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>> </modelParameter>
>>>> </eqvtbase:Transformation>
>>>>
>>>> ########### Model 2 #############
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>> <modelParameter xmi:id="ast8" name="middle">
>>>> <usedPackage
>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>> </modelParameter>
>>>> </eqvtbase:Transformation>
>>>>
>>>> ####################################
>>>>
>>>> - The only differences' I've introduced is the nsURI of the root node.
>>>>
>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>> changes on "usedPackage" EReference, indicating that
>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / " has
>>>> been
>>>> added on the first model, and deleted in the second one.
>>>>
>>>> I've been digging a little bit in the source code and noticed what's
>>>> going on.
>>>>
>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>
>>>> These four nodes are properly added to
>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>
>>>> The problem appears in "GenericDiffEngine::computeAddedReferences"
>>>> and "GenericDiffEngine::computeDeletedReferences", while trying to
>>>> retrieve from the map the matchModel of
>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>> which doesn't actually exist in "eObjectToMatch" (what makes sense,
>>>> since that reference wasn't matched during first matching phase).
>>>>
>>>>
>>>> So I guess there are two solutions:
>>>>
>>>> - Add these referenced resources to "eObjectToMatch"
>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>
>>>>
>>>> I'm sorry if I haven't been clear. If necessary, I'll send you the
>>>> example models and metamodel.
>>>>
>>>>
>>>> Best regards,
>>>> Víctor.
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125060 is a reply to message #125048] Tue, 03 June 2008 15:37 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020200050600030204010705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125073 is a reply to message #125060] Tue, 03 June 2008 15:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Laurent,

To me it does make sense to ignore derived things for much the same
reason that a copier doesn't copy them. Presumably the information is
derived from other things in the model and if there's a difference, it
will be those non-derived differences that matter.


laurent Goubet wrote:
> Víctor,
>
> Ha, we indeed ignore derived references for comparison
> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>
> /**
> * Determines if we should ignore a reference for diff detection.
> * <p>
> * Default is to ignore references marked either
> * <ul>
> * <li>Containment</li>
> * <li>Container</li>
> * <li>Transient</li>
> * <li>Derived</li>
> * </ul>
> * </p>
> * <p>
> * Clients should override this if they wish to ignore other
> references.
> * </p>
> *
> * @param reference
> * Reference to determine whether it should be ignored.
> * @return <code>True</code> if reference has to be ignored,
> <code>False</code> otherwise.
> */
> protected boolean shouldBeIgnored(EReference reference) {
> boolean ignore = reference.isContainment();
> ignore |= reference.isDerived();
> ignore |= reference.isTransient();
> ignore |= reference.isContainer();
> return ignore;
> }
>
> What I don't understand is ... if we ignore them, why are there
> differences reported on it? I wonder if this truly is the source of
> the issue but will look into it some more. Thanks for the feedback.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Hi Laurent,
>>
>> after 2 days searching, I found the source of the problem for these
>> false positives. And it's not about containment. It's about the
>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>> derived EReference (it shouldn't be that way, actually), which was
>> also container. Any model element contained by this "derived"
>> EReference was ignored by the engine during the matching. Is this a
>> correct behaviour? Should I raise a bugzilla?
>>
>> Thanks!
>>
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Yes, if there isn't any real differences, the two files are exactly
>>> the same and compare won't go through the trouble of finding other
>>> comparators (such as EMF Compare) to try and find what has been
>>> changed.
>>>
>>> Having example models would indeed be the best for us to understand
>>> the actual issue. I can easily understand that having 1 difference
>>> triggerring 45 false positives is unexploitable.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Laurent,
>>>>
>>>> these bugs seems somehow related with what I've detected: proxy
>>>> resolution and broken references. The example I posted seems to
>>>> match both of those cases. However, I've got also some invalid
>>>> diffs over references to elements on the same model. As I have
>>>> said, these multivalued refences seemed equal when I take a look at
>>>> the XMI, so there most probable reason would problems during proxy
>>>> resolution.
>>>>
>>>> Curiously enough, these false triggering only appears if there is
>>>> at least 1 real difference in the model. If the models are
>>>> completely equal, no false differences are shown.
>>>>
>>>> I have a model with one only real difference that actually returns
>>>> like 45 false differences, all related with this problem.
>>>> Unfortunately, I cant provide it since its property of the company
>>>> I work for. All I have is this false triggering over some UMLX QVT
>>>> Core instances. I'll try to get these with some public metamodels
>>>> so I can send them to you.
>>>>
>>>> Cheers,
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Hi,
>>>>>
>>>>> We already have some bugs on references resolving, namely bugs
>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>> and #229663 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>
>>>>> If the issue you encounter doesn't fit in those, could you create
>>>>> a new bug report with example models to reproduce this?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Hi!
>>>>>>
>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>> false positives (sometime too much false positives). Those occur
>>>>>> only in multivalued EReferences that are apparently equal
>>>>>> (referenced values where equal). The only different thing from
>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>> EOpposite and containment=false.
>>>>>>
>>>>>> Take a look at these two models that generate a false positive
>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>
>>>>>>
>>>>>> ########### Model 1 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ########### Model 2 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ####################################
>>>>>>
>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>> node.
>>>>>>
>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>> has been
>>>>>> added on the first model, and deleted in the second one.
>>>>>>
>>>>>> I've been digging a little bit in the source code and noticed
>>>>>> what's going on.
>>>>>>
>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>
>>>>>> These four nodes are properly added to
>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>
>>>>>> The problem appears in
>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>> retrieve from the map the matchModel of
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>> sense, since that reference wasn't matched during first matching
>>>>>> phase).
>>>>>>
>>>>>>
>>>>>> So I guess there are two solutions:
>>>>>>
>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>
>>>>>>
>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you
>>>>>> the example models and metamodel.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Víctor.
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125083 is a reply to message #125073] Tue, 03 June 2008 16:02 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050203020707020409080207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

Yup, that's the reason why we decided on ignoring it, better have a
single difference than two on this. What I do not understand here is
that we seem to detect a difference on derived references even when
ignoring them, which would be a bug ;).

Ed Merks a
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125093 is a reply to message #125060] Tue, 03 June 2008 16:07 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Laurent,

I think I know why it's repored as a difference. As far As I've seen in
the source code, every element that's matched is put into a hashmap
(GenericDiffEngine.java:82 -> eObjectToMatch), linked with a
"match2element" structure. During differences analysis, anything that is
not inside that hashmap is considered a difference (check
"computeAddedReferences" and "computeDeletedReferences" methods). Since
you ignore derived elements, these won't appear in the hashmap.

laurent Goubet escribió:
> Víctor,
>
> Ha, we indeed ignore derived references for comparison
> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>
> /**
> * Determines if we should ignore a reference for diff detection.
> * <p>
> * Default is to ignore references marked either
> * <ul>
> * <li>Containment</li>
> * <li>Container</li>
> * <li>Transient</li>
> * <li>Derived</li>
> * </ul>
> * </p>
> * <p>
> * Clients should override this if they wish to ignore other
> references.
> * </p>
> *
> * @param reference
> * Reference to determine whether it should be ignored.
> * @return <code>True</code> if reference has to be ignored,
> <code>False</code> otherwise.
> */
> protected boolean shouldBeIgnored(EReference reference) {
> boolean ignore = reference.isContainment();
> ignore |= reference.isDerived();
> ignore |= reference.isTransient();
> ignore |= reference.isContainer();
> return ignore;
> }
>
> What I don't understand is ... if we ignore them, why are there
> differences reported on it? I wonder if this truly is the source of the
> issue but will look into it some more. Thanks for the feedback.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Hi Laurent,
>>
>> after 2 days searching, I found the source of the problem for these
>> false positives. And it's not about containment. It's about the
>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>> derived EReference (it shouldn't be that way, actually), which was
>> also container. Any model element contained by this "derived"
>> EReference was ignored by the engine during the matching. Is this a
>> correct behaviour? Should I raise a bugzilla?
>>
>> Thanks!
>>
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Yes, if there isn't any real differences, the two files are exactly
>>> the same and compare won't go through the trouble of finding other
>>> comparators (such as EMF Compare) to try and find what has been changed.
>>>
>>> Having example models would indeed be the best for us to understand
>>> the actual issue. I can easily understand that having 1 difference
>>> triggerring 45 false positives is unexploitable.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Laurent,
>>>>
>>>> these bugs seems somehow related with what I've detected: proxy
>>>> resolution and broken references. The example I posted seems to
>>>> match both of those cases. However, I've got also some invalid diffs
>>>> over references to elements on the same model. As I have said, these
>>>> multivalued refences seemed equal when I take a look at the XMI, so
>>>> there most probable reason would problems during proxy resolution.
>>>>
>>>> Curiously enough, these false triggering only appears if there is at
>>>> least 1 real difference in the model. If the models are completely
>>>> equal, no false differences are shown.
>>>>
>>>> I have a model with one only real difference that actually returns
>>>> like 45 false differences, all related with this problem.
>>>> Unfortunately, I cant provide it since its property of the company I
>>>> work for. All I have is this false triggering over some UMLX QVT
>>>> Core instances. I'll try to get these with some public metamodels so
>>>> I can send them to you.
>>>>
>>>> Cheers,
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Hi,
>>>>>
>>>>> We already have some bugs on references resolving, namely bugs
>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>> and #229663 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>
>>>>> If the issue you encounter doesn't fit in those, could you create a
>>>>> new bug report with example models to reproduce this?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Hi!
>>>>>>
>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>> false positives (sometime too much false positives). Those occur
>>>>>> only in multivalued EReferences that are apparently equal
>>>>>> (referenced values where equal). The only different thing from
>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>> EOpposite and containment=false.
>>>>>>
>>>>>> Take a look at these two models that generate a false positive
>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>
>>>>>>
>>>>>> ########### Model 1 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ########### Model 2 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ####################################
>>>>>>
>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>> node.
>>>>>>
>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>> has been
>>>>>> added on the first model, and deleted in the second one.
>>>>>>
>>>>>> I've been digging a little bit in the source code and noticed
>>>>>> what's going on.
>>>>>>
>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>
>>>>>> These four nodes are properly added to
>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>
>>>>>> The problem appears in "GenericDiffEngine::computeAddedReferences"
>>>>>> and "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>> retrieve from the map the matchModel of
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>> sense, since that reference wasn't matched during first matching
>>>>>> phase).
>>>>>>
>>>>>>
>>>>>> So I guess there are two solutions:
>>>>>>
>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>
>>>>>>
>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you the
>>>>>> example models and metamodel.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Víctor.
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125121 is a reply to message #125093] Wed, 04 June 2008 08:31 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000203010606040403080209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125124 is a reply to message #125121] Wed, 04 June 2008 09:27 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Sure thing, I'll do that ASAP.

laurent Goubet escribió:
> Víctor,
>
> I can't seem to reproduce this bug with either setting I can put in a
> test metamodel :/. Could you provide us with a dummy metamodel
> presenting a reference producing this bug? Preferrably on bugzilla.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I know why it's repored as a difference. As far As I've seen
>> in the source code, every element that's matched is put into a hashmap
>> (GenericDiffEngine.java:82 -> eObjectToMatch), linked with a
>> "match2element" structure. During differences analysis, anything that
>> is not inside that hashmap is considered a difference (check
>> "computeAddedReferences" and "computeDeletedReferences" methods).
>> Since you ignore derived elements, these won't appear in the hashmap.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Ha, we indeed ignore derived references for comparison
>>> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>>>
>>> /**
>>> * Determines if we should ignore a reference for diff detection.
>>> * <p>
>>> * Default is to ignore references marked either
>>> * <ul>
>>> * <li>Containment</li>
>>> * <li>Container</li>
>>> * <li>Transient</li>
>>> * <li>Derived</li>
>>> * </ul>
>>> * </p>
>>> * <p>
>>> * Clients should override this if they wish to ignore other
>>> references.
>>> * </p>
>>> *
>>> * @param reference
>>> * Reference to determine whether it should be ignored.
>>> * @return <code>True</code> if reference has to be ignored,
>>> <code>False</code> otherwise.
>>> */
>>> protected boolean shouldBeIgnored(EReference reference) {
>>> boolean ignore = reference.isContainment();
>>> ignore |= reference.isDerived();
>>> ignore |= reference.isTransient();
>>> ignore |= reference.isContainer();
>>> return ignore;
>>> }
>>>
>>> What I don't understand is ... if we ignore them, why are there
>>> differences reported on it? I wonder if this truly is the source of
>>> the issue but will look into it some more. Thanks for the feedback.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Hi Laurent,
>>>>
>>>> after 2 days searching, I found the source of the problem for these
>>>> false positives. And it's not about containment. It's about the
>>>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>>>> derived EReference (it shouldn't be that way, actually), which was
>>>> also container. Any model element contained by this "derived"
>>>> EReference was ignored by the engine during the matching. Is this a
>>>> correct behaviour? Should I raise a bugzilla?
>>>>
>>>> Thanks!
>>>>
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Víctor,
>>>>>
>>>>> Yes, if there isn't any real differences, the two files are exactly
>>>>> the same and compare won't go through the trouble of finding other
>>>>> comparators (such as EMF Compare) to try and find what has been
>>>>> changed.
>>>>>
>>>>> Having example models would indeed be the best for us to understand
>>>>> the actual issue. I can easily understand that having 1 difference
>>>>> triggerring 45 false positives is unexploitable.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Laurent,
>>>>>>
>>>>>> these bugs seems somehow related with what I've detected: proxy
>>>>>> resolution and broken references. The example I posted seems to
>>>>>> match both of those cases. However, I've got also some invalid
>>>>>> diffs over references to elements on the same model. As I have
>>>>>> said, these multivalued refences seemed equal when I take a look
>>>>>> at the XMI, so there most probable reason would problems during
>>>>>> proxy resolution.
>>>>>>
>>>>>> Curiously enough, these false triggering only appears if there is
>>>>>> at least 1 real difference in the model. If the models are
>>>>>> completely equal, no false differences are shown.
>>>>>>
>>>>>> I have a model with one only real difference that actually returns
>>>>>> like 45 false differences, all related with this problem.
>>>>>> Unfortunately, I cant provide it since its property of the company
>>>>>> I work for. All I have is this false triggering over some UMLX QVT
>>>>>> Core instances. I'll try to get these with some public metamodels
>>>>>> so I can send them to you.
>>>>>>
>>>>>> Cheers,
>>>>>> Víctor.
>>>>>>
>>>>>> laurent Goubet escribió:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We already have some bugs on references resolving, namely bugs
>>>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>>>> and #229663 (
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>>>
>>>>>>> If the issue you encounter doesn't fit in those, could you create
>>>>>>> a new bug report with example models to reproduce this?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>>>> false positives (sometime too much false positives). Those occur
>>>>>>>> only in multivalued EReferences that are apparently equal
>>>>>>>> (referenced values where equal). The only different thing from
>>>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>>>> EOpposite and containment=false.
>>>>>>>>
>>>>>>>> Take a look at these two models that generate a false positive
>>>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>>>
>>>>>>>>
>>>>>>>> ########### Model 1 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ########### Model 2 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ####################################
>>>>>>>>
>>>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>>>> node.
>>>>>>>>
>>>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>>>> has been
>>>>>>>> added on the first model, and deleted in the second one.
>>>>>>>>
>>>>>>>> I've been digging a little bit in the source code and noticed
>>>>>>>> what's going on.
>>>>>>>>
>>>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>>>
>>>>>>>> These four nodes are properly added to
>>>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>>>
>>>>>>>> The problem appears in
>>>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>>>> retrieve from the map the matchModel of
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>>>> sense, since that reference wasn't matched during first matching
>>>>>>>> phase).
>>>>>>>>
>>>>>>>>
>>>>>>>> So I guess there are two solutions:
>>>>>>>>
>>>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you
>>>>>>>> the example models and metamodel.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Víctor.
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125132 is a reply to message #125121] Wed, 04 June 2008 14:37 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Done :)

Metamodel, genmodel, test instances and .emfdiff file.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=235606

Cheers,
Víctor

laurent Goubet escribió:
> Víctor,
>
> I can't seem to reproduce this bug with either setting I can put in a
> test metamodel :/. Could you provide us with a dummy metamodel
> presenting a reference producing this bug? Preferrably on bugzilla.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I know why it's repored as a difference. As far As I've seen
>> in the source code, every element that's matched is put into a hashmap
>> (GenericDiffEngine.java:82 -> eObjectToMatch), linked with a
>> "match2element" structure. During differences analysis, anything that
>> is not inside that hashmap is considered a difference (check
>> "computeAddedReferences" and "computeDeletedReferences" methods).
>> Since you ignore derived elements, these won't appear in the hashmap.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Ha, we indeed ignore derived references for comparison
>>> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>>>
>>> /**
>>> * Determines if we should ignore a reference for diff detection.
>>> * <p>
>>> * Default is to ignore references marked either
>>> * <ul>
>>> * <li>Containment</li>
>>> * <li>Container</li>
>>> * <li>Transient</li>
>>> * <li>Derived</li>
>>> * </ul>
>>> * </p>
>>> * <p>
>>> * Clients should override this if they wish to ignore other
>>> references.
>>> * </p>
>>> *
>>> * @param reference
>>> * Reference to determine whether it should be ignored.
>>> * @return <code>True</code> if reference has to be ignored,
>>> <code>False</code> otherwise.
>>> */
>>> protected boolean shouldBeIgnored(EReference reference) {
>>> boolean ignore = reference.isContainment();
>>> ignore |= reference.isDerived();
>>> ignore |= reference.isTransient();
>>> ignore |= reference.isContainer();
>>> return ignore;
>>> }
>>>
>>> What I don't understand is ... if we ignore them, why are there
>>> differences reported on it? I wonder if this truly is the source of
>>> the issue but will look into it some more. Thanks for the feedback.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Hi Laurent,
>>>>
>>>> after 2 days searching, I found the source of the problem for these
>>>> false positives. And it's not about containment. It's about the
>>>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>>>> derived EReference (it shouldn't be that way, actually), which was
>>>> also container. Any model element contained by this "derived"
>>>> EReference was ignored by the engine during the matching. Is this a
>>>> correct behaviour? Should I raise a bugzilla?
>>>>
>>>> Thanks!
>>>>
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Víctor,
>>>>>
>>>>> Yes, if there isn't any real differences, the two files are exactly
>>>>> the same and compare won't go through the trouble of finding other
>>>>> comparators (such as EMF Compare) to try and find what has been
>>>>> changed.
>>>>>
>>>>> Having example models would indeed be the best for us to understand
>>>>> the actual issue. I can easily understand that having 1 difference
>>>>> triggerring 45 false positives is unexploitable.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Laurent,
>>>>>>
>>>>>> these bugs seems somehow related with what I've detected: proxy
>>>>>> resolution and broken references. The example I posted seems to
>>>>>> match both of those cases. However, I've got also some invalid
>>>>>> diffs over references to elements on the same model. As I have
>>>>>> said, these multivalued refences seemed equal when I take a look
>>>>>> at the XMI, so there most probable reason would problems during
>>>>>> proxy resolution.
>>>>>>
>>>>>> Curiously enough, these false triggering only appears if there is
>>>>>> at least 1 real difference in the model. If the models are
>>>>>> completely equal, no false differences are shown.
>>>>>>
>>>>>> I have a model with one only real difference that actually returns
>>>>>> like 45 false differences, all related with this problem.
>>>>>> Unfortunately, I cant provide it since its property of the company
>>>>>> I work for. All I have is this false triggering over some UMLX QVT
>>>>>> Core instances. I'll try to get these with some public metamodels
>>>>>> so I can send them to you.
>>>>>>
>>>>>> Cheers,
>>>>>> Víctor.
>>>>>>
>>>>>> laurent Goubet escribió:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We already have some bugs on references resolving, namely bugs
>>>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>>>> and #229663 (
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>>>
>>>>>>> If the issue you encounter doesn't fit in those, could you create
>>>>>>> a new bug report with example models to reproduce this?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>>>> false positives (sometime too much false positives). Those occur
>>>>>>>> only in multivalued EReferences that are apparently equal
>>>>>>>> (referenced values where equal). The only different thing from
>>>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>>>> EOpposite and containment=false.
>>>>>>>>
>>>>>>>> Take a look at these two models that generate a false positive
>>>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>>>
>>>>>>>>
>>>>>>>> ########### Model 1 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ########### Model 2 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ####################################
>>>>>>>>
>>>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>>>> node.
>>>>>>>>
>>>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>>>> has been
>>>>>>>> added on the first model, and deleted in the second one.
>>>>>>>>
>>>>>>>> I've been digging a little bit in the source code and noticed
>>>>>>>> what's going on.
>>>>>>>>
>>>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>>>
>>>>>>>> These four nodes are properly added to
>>>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>>>
>>>>>>>> The problem appears in
>>>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>>>> retrieve from the map the matchModel of
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>>>> sense, since that reference wasn't matched during first matching
>>>>>>>> phase).
>>>>>>>>
>>>>>>>>
>>>>>>>> So I guess there are two solutions:
>>>>>>>>
>>>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you
>>>>>>>> the example models and metamodel.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Víctor.
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125154 is a reply to message #125132] Thu, 05 June 2008 14:02 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050004070602070402010902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Thanks for that ;). The issue didn't come from the diff engine
(difference detection) but rather from the match engine (elements
mapping). the content of a derived containment difference doesn't appear
in the eobject's content list (EObject#eContents() /
EObject#eAllContents()) so we weren't able to match them and they were
detected as differences.

Ed, is this a bug in EMF or derived references weren't meant to appear
in the content list event when they are containment references?

Thanks for the feedback!

Laurent Goubet
Obeo

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125160 is a reply to message #125154] Thu, 05 June 2008 17:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Laurent,

The problem with a derived containment reference is that you can't
really derive a containment reference; Kenn ran into this issue with UML
as well with subset/superset features. The only scenario where EMF
supports such a thing directly is in the case where the feature derives
from the information in a feature map, and in that case, we ensure that
the contents derived from the feature map are properly included in the
right order where the feature map determines the order. Some of the
problems with trying to make this work are issues like the eContainer
must be consistent and in particular
x.eContainer().eGet(x.eContainmentFeature()) must return x or a list
containing x. So if the containment reference derives from another
containment reference, the containment feature isn't consistent. If the
containment reference derives from a non-containment reference, it's
hard to imagine that the eContainer will be correct. So it's likely
that there's something inconsistent about a model that has derived
containment features. The subject line talks about multi-valued
non-containment references which makes me think that the derivation is
perhaps done in a bad direction. I.e., while it's fine to derive a
non-containment reference from a containment reference, the other
direction doesn't work well at all.


laurent Goubet wrote:
> Thanks for that ;). The issue didn't come from the diff engine
> (difference detection) but rather from the match engine (elements
> mapping). the content of a derived containment difference doesn't
> appear in the eobject's content list (EObject#eContents() /
> EObject#eAllContents()) so we weren't able to match them and they were
> detected as differences.
>
> Ed, is this a bug in EMF or derived references weren't meant to appear
> in the content list event when they are containment references?
>
> Thanks for the feedback!
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Done :)
>>
>> Metamodel, genmodel, test instances and .emfdiff file.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=235606
>>
>> Cheers,
>> Víctor
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> I can't seem to reproduce this bug with either setting I can put in
>>> a test metamodel :/. Could you provide us with a dummy metamodel
>>> presenting a reference producing this bug? Preferrably on bugzilla.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Laurent,
>>>>
>>>> I think I know why it's repored as a difference. As far As I've
>>>> seen in the source code, every element that's matched is put into a
>>>> hashmap (GenericDiffEngine.java:82 -> eObjectToMatch), linked with
>>>> a "match2element" structure. During differences analysis, anything
>>>> that is not inside that hashmap is considered a difference (check
>>>> "computeAddedReferences" and "computeDeletedReferences" methods).
>>>> Since you ignore derived elements, these won't appear in the hashmap.
>>>>
>>>> laurent Goubet escribió:
>>>>> Víctor,
>>>>>
>>>>> Ha, we indeed ignore derived references for comparison
>>>>> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>>>>>
>>>>> /**
>>>>> * Determines if we should ignore a reference for diff detection.
>>>>> * <p>
>>>>> * Default is to ignore references marked either
>>>>> * <ul>
>>>>> * <li>Containment</li>
>>>>> * <li>Container</li>
>>>>> * <li>Transient</li>
>>>>> * <li>Derived</li>
>>>>> * </ul>
>>>>> * </p>
>>>>> * <p>
>>>>> * Clients should override this if they wish to ignore other
>>>>> references.
>>>>> * </p>
>>>>> *
>>>>> * @param reference
>>>>> * Reference to determine whether it should be
>>>>> ignored.
>>>>> * @return <code>True</code> if reference has to be ignored,
>>>>> <code>False</code> otherwise.
>>>>> */
>>>>> protected boolean shouldBeIgnored(EReference reference) {
>>>>> boolean ignore = reference.isContainment();
>>>>> ignore |= reference.isDerived();
>>>>> ignore |= reference.isTransient();
>>>>> ignore |= reference.isContainer();
>>>>> return ignore;
>>>>> }
>>>>>
>>>>> What I don't understand is ... if we ignore them, why are there
>>>>> differences reported on it? I wonder if this truly is the source
>>>>> of the issue but will look into it some more. Thanks for the
>>>>> feedback.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Hi Laurent,
>>>>>>
>>>>>> after 2 days searching, I found the source of the problem for
>>>>>> these false positives. And it's not about containment. It's about
>>>>>> the "derived" attribute of an EAttribute/EReference. In my case,
>>>>>> I had a derived EReference (it shouldn't be that way, actually),
>>>>>> which was also container. Any model element contained by this
>>>>>> "derived" EReference was ignored by the engine during the
>>>>>> matching. Is this a correct behaviour? Should I raise a bugzilla?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Víctor.
>>>>>>
>>>>>> laurent Goubet escribió:
>>>>>>> Víctor,
>>>>>>>
>>>>>>> Yes, if there isn't any real differences, the two files are
>>>>>>> exactly the same and compare won't go through the trouble of
>>>>>>> finding other comparators (such as EMF Compare) to try and find
>>>>>>> what has been changed.
>>>>>>>
>>>>>>> Having example models would indeed be the best for us to
>>>>>>> understand the actual issue. I can easily understand that having
>>>>>>> 1 difference triggerring 45 false positives is unexploitable.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>> Laurent,
>>>>>>>>
>>>>>>>> these bugs seems somehow related with what I've detected: proxy
>>>>>>>> resolution and broken references. The example I posted seems to
>>>>>>>> match both of those cases. However, I've got also some invalid
>>>>>>>> diffs over references to elements on the same model. As I have
>>>>>>>> said, these multivalued refences seemed equal when I take a
>>>>>>>> look at the XMI, so there most probable reason would problems
>>>>>>>> during proxy resolution.
>>>>>>>>
>>>>>>>> Curiously enough, these false triggering only appears if there
>>>>>>>> is at least 1 real difference in the model. If the models are
>>>>>>>> completely equal, no false differences are shown.
>>>>>>>>
>>>>>>>> I have a model with one only real difference that actually
>>>>>>>> returns like 45 false differences, all related with this
>>>>>>>> problem. Unfortunately, I cant provide it since its property of
>>>>>>>> the company I work for. All I have is this false triggering
>>>>>>>> over some UMLX QVT Core instances. I'll try to get these with
>>>>>>>> some public metamodels so I can send them to you.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Víctor.
>>>>>>>>
>>>>>>>> laurent Goubet escribió:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We already have some bugs on references resolving, namely bugs
>>>>>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877
>>>>>>>>> ) and #229663 (
>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>>>>>
>>>>>>>>> If the issue you encounter doesn't fit in those, could you
>>>>>>>>> create a new bug report with example models to reproduce this?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Laurent Goubet
>>>>>>>>> Obeo
>>>>>>>>>
>>>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I've used EMF Compare with some models of mine, receiving
>>>>>>>>>> some false positives (sometime too much false positives).
>>>>>>>>>> Those occur only in multivalued EReferences that are
>>>>>>>>>> apparently equal (referenced values where equal). The only
>>>>>>>>>> different thing from other ERefereces of the same metamodel
>>>>>>>>>> I've noticed is having no EOpposite and containment=false.
>>>>>>>>>>
>>>>>>>>>> Take a look at these two models that generate a false
>>>>>>>>>> positive (using UMLX's QVT Core metamodel):
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ########### Model 1 #############
>>>>>>>>>>
>>>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms"
>>>>>>>>>> nsPrefix="umlRdbms">
>>>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>>>> <usedPackage
>>>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>>>
>>>>>>>>>> </modelParameter>
>>>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>>>
>>>>>>>>>> ########### Model 2 #############
>>>>>>>>>>
>>>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>>>> <usedPackage
>>>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>>>
>>>>>>>>>> </modelParameter>
>>>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>>>
>>>>>>>>>> ####################################
>>>>>>>>>>
>>>>>>>>>> - The only differences' I've introduced is the nsURI of the
>>>>>>>>>> root node.
>>>>>>>>>>
>>>>>>>>>> EMF Compare shows correctly the changes on the nsURI, but
>>>>>>>>>> also changes on "usedPackage" EReference, indicating that
>>>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>>>>>> has been
>>>>>>>>>> added on the first model, and deleted in the second one.
>>>>>>>>>>
>>>>>>>>>> I've been digging a little bit in the source code and noticed
>>>>>>>>>> what's going on.
>>>>>>>>>>
>>>>>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>>>>>
>>>>>>>>>> These four nodes are properly added to
>>>>>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>>>>>
>>>>>>>>>> The problem appears in
>>>>>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying
>>>>>>>>>> to retrieve from the map the matchModel of
>>>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>>>>>> sense, since that reference wasn't matched during first
>>>>>>>>>> matching phase).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So I guess there are two solutions:
>>>>>>>>>>
>>>>>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..."
>>>>>>>>>> returns
>>>>>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate"
>>>>>>>>>> method)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send
>>>>>>>>>> you the example models and metamodel.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Víctor.
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #125175 is a reply to message #125160] Fri, 06 June 2008 07:32 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090109060409090606050500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

Yes, I can understand the problem with such references. And As V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619094 is a reply to message #123636] Fri, 30 May 2008 07:43 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080104060404080102060603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

We already have some bugs on references resolving, namely bugs #199877 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 ) and #229663 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).

If the issue you encounter doesn't fit in those, could you create a new
bug report with example models to reproduce this?

Thanks!

Laurent Goubet
Obeo

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619140 is a reply to message #124027] Mon, 02 June 2008 10:45 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Laurent,

these bugs seems somehow related with what I've detected: proxy
resolution and broken references. The example I posted seems to match
both of those cases. However, I've got also some invalid diffs over
references to elements on the same model. As I have said, these
multivalued refences seemed equal when I take a look at the XMI, so
there most probable reason would problems during proxy resolution.

Curiously enough, these false triggering only appears if there is at
least 1 real difference in the model. If the models are completely
equal, no false differences are shown.

I have a model with one only real difference that actually returns like
45 false differences, all related with this problem. Unfortunately, I
cant provide it since its property of the company I work for. All I have
is this false triggering over some UMLX QVT Core instances. I'll try to
get these with some public metamodels so I can send them to you.

Cheers,
Víctor.

laurent Goubet escribió:
> Hi,
>
> We already have some bugs on references resolving, namely bugs #199877 (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 ) and #229663 (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>
> If the issue you encounter doesn't fit in those, could you create a new
> bug report with example models to reproduce this?
>
> Thanks!
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Hi!
>>
>> I've used EMF Compare with some models of mine, receiving some false
>> positives (sometime too much false positives). Those occur only in
>> multivalued EReferences that are apparently equal (referenced values
>> where equal). The only different thing from other ERefereces of the
>> same metamodel I've noticed is having no EOpposite and containment=false.
>>
>> Take a look at these two models that generate a false positive (using
>> UMLX's QVT Core metamodel):
>>
>>
>> ########### Model 1 #############
>>
>> <?xml version="1.0" encoding="ASCII"?>
>> <eqvtbase:Transformation xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>> <modelParameter xmi:id="ast8" name="middle">
>> <usedPackage
>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>> </modelParameter>
>> </eqvtbase:Transformation>
>>
>> ########### Model 2 #############
>>
>> <?xml version="1.0" encoding="ASCII"?>
>> <eqvtbase:Transformation xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>> <modelParameter xmi:id="ast8" name="middle">
>> <usedPackage
>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>> </modelParameter>
>> </eqvtbase:Transformation>
>>
>> ####################################
>>
>> - The only differences' I've introduced is the nsURI of the root node.
>>
>> EMF Compare shows correctly the changes on the nsURI, but also changes
>> on "usedPackage" EReference, indicating that
>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / " has been
>> added on the first model, and deleted in the second one.
>>
>> I've been digging a little bit in the source code and noticed what's
>> going on.
>>
>> - Root node is marked as not equal (similarity = 0.6....)
>> - Typed model node is marked as equal (similarity = 1.0)
>>
>> These four nodes are properly added to
>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>
>> The problem appears in "GenericDiffEngine::computeAddedReferences" and
>> "GenericDiffEngine::computeDeletedReferences", while trying to
>> retrieve from the map the matchModel of
>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ", which
>> doesn't actually exist in "eObjectToMatch" (what makes sense, since
>> that reference wasn't matched during first matching phase).
>>
>>
>> So I guess there are two solutions:
>>
>> - Add these referenced resources to "eObjectToMatch"
>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>
>>
>> I'm sorry if I haven't been clear. If necessary, I'll send you the
>> example models and metamodel.
>>
>>
>> Best regards,
>> Víctor.
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619142 is a reply to message #124847] Mon, 02 June 2008 11:38 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010006020507080801070700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619156 is a reply to message #124872] Tue, 03 June 2008 15:26 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Laurent,

after 2 days searching, I found the source of the problem for these
false positives. And it's not about containment. It's about the
"derived" attribute of an EAttribute/EReference. In my case, I had a
derived EReference (it shouldn't be that way, actually), which was also
container. Any model element contained by this "derived" EReference was
ignored by the engine during the matching. Is this a correct behaviour?
Should I raise a bugzilla?

Thanks!

Víctor.

laurent Goubet escribió:
> Víctor,
>
> Yes, if there isn't any real differences, the two files are exactly the
> same and compare won't go through the trouble of finding other
> comparators (such as EMF Compare) to try and find what has been changed.
>
> Having example models would indeed be the best for us to understand the
> actual issue. I can easily understand that having 1 difference
> triggerring 45 false positives is unexploitable.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> these bugs seems somehow related with what I've detected: proxy
>> resolution and broken references. The example I posted seems to match
>> both of those cases. However, I've got also some invalid diffs over
>> references to elements on the same model. As I have said, these
>> multivalued refences seemed equal when I take a look at the XMI, so
>> there most probable reason would problems during proxy resolution.
>>
>> Curiously enough, these false triggering only appears if there is at
>> least 1 real difference in the model. If the models are completely
>> equal, no false differences are shown.
>>
>> I have a model with one only real difference that actually returns
>> like 45 false differences, all related with this problem.
>> Unfortunately, I cant provide it since its property of the company I
>> work for. All I have is this false triggering over some UMLX QVT Core
>> instances. I'll try to get these with some public metamodels so I can
>> send them to you.
>>
>> Cheers,
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Hi,
>>>
>>> We already have some bugs on references resolving, namely bugs
>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 ) and
>>> #229663 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>
>>> If the issue you encounter doesn't fit in those, could you create a
>>> new bug report with example models to reproduce this?
>>>
>>> Thanks!
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Hi!
>>>>
>>>> I've used EMF Compare with some models of mine, receiving some false
>>>> positives (sometime too much false positives). Those occur only in
>>>> multivalued EReferences that are apparently equal (referenced values
>>>> where equal). The only different thing from other ERefereces of the
>>>> same metamodel I've noticed is having no EOpposite and
>>>> containment=false.
>>>>
>>>> Take a look at these two models that generate a false positive
>>>> (using UMLX's QVT Core metamodel):
>>>>
>>>>
>>>> ########### Model 1 #############
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>> <modelParameter xmi:id="ast8" name="middle">
>>>> <usedPackage
>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>> </modelParameter>
>>>> </eqvtbase:Transformation>
>>>>
>>>> ########### Model 2 #############
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>> <modelParameter xmi:id="ast8" name="middle">
>>>> <usedPackage
>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>> </modelParameter>
>>>> </eqvtbase:Transformation>
>>>>
>>>> ####################################
>>>>
>>>> - The only differences' I've introduced is the nsURI of the root node.
>>>>
>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>> changes on "usedPackage" EReference, indicating that
>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / " has
>>>> been
>>>> added on the first model, and deleted in the second one.
>>>>
>>>> I've been digging a little bit in the source code and noticed what's
>>>> going on.
>>>>
>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>
>>>> These four nodes are properly added to
>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>
>>>> The problem appears in "GenericDiffEngine::computeAddedReferences"
>>>> and "GenericDiffEngine::computeDeletedReferences", while trying to
>>>> retrieve from the map the matchModel of
>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>> which doesn't actually exist in "eObjectToMatch" (what makes sense,
>>>> since that reference wasn't matched during first matching phase).
>>>>
>>>>
>>>> So I guess there are two solutions:
>>>>
>>>> - Add these referenced resources to "eObjectToMatch"
>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>
>>>>
>>>> I'm sorry if I haven't been clear. If necessary, I'll send you the
>>>> example models and metamodel.
>>>>
>>>>
>>>> Best regards,
>>>> Víctor.
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619157 is a reply to message #125048] Tue, 03 June 2008 15:37 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020200050600030204010705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619158 is a reply to message #125060] Tue, 03 June 2008 15:50 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31032
Registered: July 2009
Senior Member
Laurent,

To me it does make sense to ignore derived things for much the same
reason that a copier doesn't copy them. Presumably the information is
derived from other things in the model and if there's a difference, it
will be those non-derived differences that matter.


laurent Goubet wrote:
> Víctor,
>
> Ha, we indeed ignore derived references for comparison
> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>
> /**
> * Determines if we should ignore a reference for diff detection.
> * <p>
> * Default is to ignore references marked either
> * <ul>
> * <li>Containment</li>
> * <li>Container</li>
> * <li>Transient</li>
> * <li>Derived</li>
> * </ul>
> * </p>
> * <p>
> * Clients should override this if they wish to ignore other
> references.
> * </p>
> *
> * @param reference
> * Reference to determine whether it should be ignored.
> * @return <code>True</code> if reference has to be ignored,
> <code>False</code> otherwise.
> */
> protected boolean shouldBeIgnored(EReference reference) {
> boolean ignore = reference.isContainment();
> ignore |= reference.isDerived();
> ignore |= reference.isTransient();
> ignore |= reference.isContainer();
> return ignore;
> }
>
> What I don't understand is ... if we ignore them, why are there
> differences reported on it? I wonder if this truly is the source of
> the issue but will look into it some more. Thanks for the feedback.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Hi Laurent,
>>
>> after 2 days searching, I found the source of the problem for these
>> false positives. And it's not about containment. It's about the
>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>> derived EReference (it shouldn't be that way, actually), which was
>> also container. Any model element contained by this "derived"
>> EReference was ignored by the engine during the matching. Is this a
>> correct behaviour? Should I raise a bugzilla?
>>
>> Thanks!
>>
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Yes, if there isn't any real differences, the two files are exactly
>>> the same and compare won't go through the trouble of finding other
>>> comparators (such as EMF Compare) to try and find what has been
>>> changed.
>>>
>>> Having example models would indeed be the best for us to understand
>>> the actual issue. I can easily understand that having 1 difference
>>> triggerring 45 false positives is unexploitable.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Laurent,
>>>>
>>>> these bugs seems somehow related with what I've detected: proxy
>>>> resolution and broken references. The example I posted seems to
>>>> match both of those cases. However, I've got also some invalid
>>>> diffs over references to elements on the same model. As I have
>>>> said, these multivalued refences seemed equal when I take a look at
>>>> the XMI, so there most probable reason would problems during proxy
>>>> resolution.
>>>>
>>>> Curiously enough, these false triggering only appears if there is
>>>> at least 1 real difference in the model. If the models are
>>>> completely equal, no false differences are shown.
>>>>
>>>> I have a model with one only real difference that actually returns
>>>> like 45 false differences, all related with this problem.
>>>> Unfortunately, I cant provide it since its property of the company
>>>> I work for. All I have is this false triggering over some UMLX QVT
>>>> Core instances. I'll try to get these with some public metamodels
>>>> so I can send them to you.
>>>>
>>>> Cheers,
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Hi,
>>>>>
>>>>> We already have some bugs on references resolving, namely bugs
>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>> and #229663 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>
>>>>> If the issue you encounter doesn't fit in those, could you create
>>>>> a new bug report with example models to reproduce this?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Hi!
>>>>>>
>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>> false positives (sometime too much false positives). Those occur
>>>>>> only in multivalued EReferences that are apparently equal
>>>>>> (referenced values where equal). The only different thing from
>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>> EOpposite and containment=false.
>>>>>>
>>>>>> Take a look at these two models that generate a false positive
>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>
>>>>>>
>>>>>> ########### Model 1 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ########### Model 2 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ####################################
>>>>>>
>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>> node.
>>>>>>
>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>> has been
>>>>>> added on the first model, and deleted in the second one.
>>>>>>
>>>>>> I've been digging a little bit in the source code and noticed
>>>>>> what's going on.
>>>>>>
>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>
>>>>>> These four nodes are properly added to
>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>
>>>>>> The problem appears in
>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>> retrieve from the map the matchModel of
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>> sense, since that reference wasn't matched during first matching
>>>>>> phase).
>>>>>>
>>>>>>
>>>>>> So I guess there are two solutions:
>>>>>>
>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>
>>>>>>
>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you
>>>>>> the example models and metamodel.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Víctor.
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619159 is a reply to message #125073] Tue, 03 June 2008 16:02 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050203020707020409080207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

Yup, that's the reason why we decided on ignoring it, better have a
single difference than two on this. What I do not understand here is
that we seem to detect a difference on derived references even when
ignoring them, which would be a bug ;).

Ed Merks a
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619160 is a reply to message #125060] Tue, 03 June 2008 16:07 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Laurent,

I think I know why it's repored as a difference. As far As I've seen in
the source code, every element that's matched is put into a hashmap
(GenericDiffEngine.java:82 -> eObjectToMatch), linked with a
"match2element" structure. During differences analysis, anything that is
not inside that hashmap is considered a difference (check
"computeAddedReferences" and "computeDeletedReferences" methods). Since
you ignore derived elements, these won't appear in the hashmap.

laurent Goubet escribió:
> Víctor,
>
> Ha, we indeed ignore derived references for comparison
> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>
> /**
> * Determines if we should ignore a reference for diff detection.
> * <p>
> * Default is to ignore references marked either
> * <ul>
> * <li>Containment</li>
> * <li>Container</li>
> * <li>Transient</li>
> * <li>Derived</li>
> * </ul>
> * </p>
> * <p>
> * Clients should override this if they wish to ignore other
> references.
> * </p>
> *
> * @param reference
> * Reference to determine whether it should be ignored.
> * @return <code>True</code> if reference has to be ignored,
> <code>False</code> otherwise.
> */
> protected boolean shouldBeIgnored(EReference reference) {
> boolean ignore = reference.isContainment();
> ignore |= reference.isDerived();
> ignore |= reference.isTransient();
> ignore |= reference.isContainer();
> return ignore;
> }
>
> What I don't understand is ... if we ignore them, why are there
> differences reported on it? I wonder if this truly is the source of the
> issue but will look into it some more. Thanks for the feedback.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Hi Laurent,
>>
>> after 2 days searching, I found the source of the problem for these
>> false positives. And it's not about containment. It's about the
>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>> derived EReference (it shouldn't be that way, actually), which was
>> also container. Any model element contained by this "derived"
>> EReference was ignored by the engine during the matching. Is this a
>> correct behaviour? Should I raise a bugzilla?
>>
>> Thanks!
>>
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Yes, if there isn't any real differences, the two files are exactly
>>> the same and compare won't go through the trouble of finding other
>>> comparators (such as EMF Compare) to try and find what has been changed.
>>>
>>> Having example models would indeed be the best for us to understand
>>> the actual issue. I can easily understand that having 1 difference
>>> triggerring 45 false positives is unexploitable.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Laurent,
>>>>
>>>> these bugs seems somehow related with what I've detected: proxy
>>>> resolution and broken references. The example I posted seems to
>>>> match both of those cases. However, I've got also some invalid diffs
>>>> over references to elements on the same model. As I have said, these
>>>> multivalued refences seemed equal when I take a look at the XMI, so
>>>> there most probable reason would problems during proxy resolution.
>>>>
>>>> Curiously enough, these false triggering only appears if there is at
>>>> least 1 real difference in the model. If the models are completely
>>>> equal, no false differences are shown.
>>>>
>>>> I have a model with one only real difference that actually returns
>>>> like 45 false differences, all related with this problem.
>>>> Unfortunately, I cant provide it since its property of the company I
>>>> work for. All I have is this false triggering over some UMLX QVT
>>>> Core instances. I'll try to get these with some public metamodels so
>>>> I can send them to you.
>>>>
>>>> Cheers,
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Hi,
>>>>>
>>>>> We already have some bugs on references resolving, namely bugs
>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>> and #229663 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>
>>>>> If the issue you encounter doesn't fit in those, could you create a
>>>>> new bug report with example models to reproduce this?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Hi!
>>>>>>
>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>> false positives (sometime too much false positives). Those occur
>>>>>> only in multivalued EReferences that are apparently equal
>>>>>> (referenced values where equal). The only different thing from
>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>> EOpposite and containment=false.
>>>>>>
>>>>>> Take a look at these two models that generate a false positive
>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>
>>>>>>
>>>>>> ########### Model 1 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ########### Model 2 #############
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>> <usedPackage
>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>
>>>>>> </modelParameter>
>>>>>> </eqvtbase:Transformation>
>>>>>>
>>>>>> ####################################
>>>>>>
>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>> node.
>>>>>>
>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>> has been
>>>>>> added on the first model, and deleted in the second one.
>>>>>>
>>>>>> I've been digging a little bit in the source code and noticed
>>>>>> what's going on.
>>>>>>
>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>
>>>>>> These four nodes are properly added to
>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>
>>>>>> The problem appears in "GenericDiffEngine::computeAddedReferences"
>>>>>> and "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>> retrieve from the map the matchModel of
>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>> sense, since that reference wasn't matched during first matching
>>>>>> phase).
>>>>>>
>>>>>>
>>>>>> So I guess there are two solutions:
>>>>>>
>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>
>>>>>>
>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you the
>>>>>> example models and metamodel.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Víctor.
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619164 is a reply to message #125093] Wed, 04 June 2008 08:31 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000203010606040403080209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619165 is a reply to message #125121] Wed, 04 June 2008 09:27 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Sure thing, I'll do that ASAP.

laurent Goubet escribió:
> Víctor,
>
> I can't seem to reproduce this bug with either setting I can put in a
> test metamodel :/. Could you provide us with a dummy metamodel
> presenting a reference producing this bug? Preferrably on bugzilla.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I know why it's repored as a difference. As far As I've seen
>> in the source code, every element that's matched is put into a hashmap
>> (GenericDiffEngine.java:82 -> eObjectToMatch), linked with a
>> "match2element" structure. During differences analysis, anything that
>> is not inside that hashmap is considered a difference (check
>> "computeAddedReferences" and "computeDeletedReferences" methods).
>> Since you ignore derived elements, these won't appear in the hashmap.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Ha, we indeed ignore derived references for comparison
>>> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>>>
>>> /**
>>> * Determines if we should ignore a reference for diff detection.
>>> * <p>
>>> * Default is to ignore references marked either
>>> * <ul>
>>> * <li>Containment</li>
>>> * <li>Container</li>
>>> * <li>Transient</li>
>>> * <li>Derived</li>
>>> * </ul>
>>> * </p>
>>> * <p>
>>> * Clients should override this if they wish to ignore other
>>> references.
>>> * </p>
>>> *
>>> * @param reference
>>> * Reference to determine whether it should be ignored.
>>> * @return <code>True</code> if reference has to be ignored,
>>> <code>False</code> otherwise.
>>> */
>>> protected boolean shouldBeIgnored(EReference reference) {
>>> boolean ignore = reference.isContainment();
>>> ignore |= reference.isDerived();
>>> ignore |= reference.isTransient();
>>> ignore |= reference.isContainer();
>>> return ignore;
>>> }
>>>
>>> What I don't understand is ... if we ignore them, why are there
>>> differences reported on it? I wonder if this truly is the source of
>>> the issue but will look into it some more. Thanks for the feedback.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Hi Laurent,
>>>>
>>>> after 2 days searching, I found the source of the problem for these
>>>> false positives. And it's not about containment. It's about the
>>>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>>>> derived EReference (it shouldn't be that way, actually), which was
>>>> also container. Any model element contained by this "derived"
>>>> EReference was ignored by the engine during the matching. Is this a
>>>> correct behaviour? Should I raise a bugzilla?
>>>>
>>>> Thanks!
>>>>
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Víctor,
>>>>>
>>>>> Yes, if there isn't any real differences, the two files are exactly
>>>>> the same and compare won't go through the trouble of finding other
>>>>> comparators (such as EMF Compare) to try and find what has been
>>>>> changed.
>>>>>
>>>>> Having example models would indeed be the best for us to understand
>>>>> the actual issue. I can easily understand that having 1 difference
>>>>> triggerring 45 false positives is unexploitable.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Laurent,
>>>>>>
>>>>>> these bugs seems somehow related with what I've detected: proxy
>>>>>> resolution and broken references. The example I posted seems to
>>>>>> match both of those cases. However, I've got also some invalid
>>>>>> diffs over references to elements on the same model. As I have
>>>>>> said, these multivalued refences seemed equal when I take a look
>>>>>> at the XMI, so there most probable reason would problems during
>>>>>> proxy resolution.
>>>>>>
>>>>>> Curiously enough, these false triggering only appears if there is
>>>>>> at least 1 real difference in the model. If the models are
>>>>>> completely equal, no false differences are shown.
>>>>>>
>>>>>> I have a model with one only real difference that actually returns
>>>>>> like 45 false differences, all related with this problem.
>>>>>> Unfortunately, I cant provide it since its property of the company
>>>>>> I work for. All I have is this false triggering over some UMLX QVT
>>>>>> Core instances. I'll try to get these with some public metamodels
>>>>>> so I can send them to you.
>>>>>>
>>>>>> Cheers,
>>>>>> Víctor.
>>>>>>
>>>>>> laurent Goubet escribió:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We already have some bugs on references resolving, namely bugs
>>>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>>>> and #229663 (
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>>>
>>>>>>> If the issue you encounter doesn't fit in those, could you create
>>>>>>> a new bug report with example models to reproduce this?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>>>> false positives (sometime too much false positives). Those occur
>>>>>>>> only in multivalued EReferences that are apparently equal
>>>>>>>> (referenced values where equal). The only different thing from
>>>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>>>> EOpposite and containment=false.
>>>>>>>>
>>>>>>>> Take a look at these two models that generate a false positive
>>>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>>>
>>>>>>>>
>>>>>>>> ########### Model 1 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ########### Model 2 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ####################################
>>>>>>>>
>>>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>>>> node.
>>>>>>>>
>>>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>>>> has been
>>>>>>>> added on the first model, and deleted in the second one.
>>>>>>>>
>>>>>>>> I've been digging a little bit in the source code and noticed
>>>>>>>> what's going on.
>>>>>>>>
>>>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>>>
>>>>>>>> These four nodes are properly added to
>>>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>>>
>>>>>>>> The problem appears in
>>>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>>>> retrieve from the map the matchModel of
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>>>> sense, since that reference wasn't matched during first matching
>>>>>>>> phase).
>>>>>>>>
>>>>>>>>
>>>>>>>> So I guess there are two solutions:
>>>>>>>>
>>>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you
>>>>>>>> the example models and metamodel.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Víctor.
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619167 is a reply to message #125121] Wed, 04 June 2008 14:37 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Done :)

Metamodel, genmodel, test instances and .emfdiff file.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=235606

Cheers,
Víctor

laurent Goubet escribió:
> Víctor,
>
> I can't seem to reproduce this bug with either setting I can put in a
> test metamodel :/. Could you provide us with a dummy metamodel
> presenting a reference producing this bug? Preferrably on bugzilla.
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I know why it's repored as a difference. As far As I've seen
>> in the source code, every element that's matched is put into a hashmap
>> (GenericDiffEngine.java:82 -> eObjectToMatch), linked with a
>> "match2element" structure. During differences analysis, anything that
>> is not inside that hashmap is considered a difference (check
>> "computeAddedReferences" and "computeDeletedReferences" methods).
>> Since you ignore derived elements, these won't appear in the hashmap.
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> Ha, we indeed ignore derived references for comparison
>>> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>>>
>>> /**
>>> * Determines if we should ignore a reference for diff detection.
>>> * <p>
>>> * Default is to ignore references marked either
>>> * <ul>
>>> * <li>Containment</li>
>>> * <li>Container</li>
>>> * <li>Transient</li>
>>> * <li>Derived</li>
>>> * </ul>
>>> * </p>
>>> * <p>
>>> * Clients should override this if they wish to ignore other
>>> references.
>>> * </p>
>>> *
>>> * @param reference
>>> * Reference to determine whether it should be ignored.
>>> * @return <code>True</code> if reference has to be ignored,
>>> <code>False</code> otherwise.
>>> */
>>> protected boolean shouldBeIgnored(EReference reference) {
>>> boolean ignore = reference.isContainment();
>>> ignore |= reference.isDerived();
>>> ignore |= reference.isTransient();
>>> ignore |= reference.isContainer();
>>> return ignore;
>>> }
>>>
>>> What I don't understand is ... if we ignore them, why are there
>>> differences reported on it? I wonder if this truly is the source of
>>> the issue but will look into it some more. Thanks for the feedback.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Hi Laurent,
>>>>
>>>> after 2 days searching, I found the source of the problem for these
>>>> false positives. And it's not about containment. It's about the
>>>> "derived" attribute of an EAttribute/EReference. In my case, I had a
>>>> derived EReference (it shouldn't be that way, actually), which was
>>>> also container. Any model element contained by this "derived"
>>>> EReference was ignored by the engine during the matching. Is this a
>>>> correct behaviour? Should I raise a bugzilla?
>>>>
>>>> Thanks!
>>>>
>>>> Víctor.
>>>>
>>>> laurent Goubet escribió:
>>>>> Víctor,
>>>>>
>>>>> Yes, if there isn't any real differences, the two files are exactly
>>>>> the same and compare won't go through the trouble of finding other
>>>>> comparators (such as EMF Compare) to try and find what has been
>>>>> changed.
>>>>>
>>>>> Having example models would indeed be the best for us to understand
>>>>> the actual issue. I can easily understand that having 1 difference
>>>>> triggerring 45 false positives is unexploitable.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Laurent,
>>>>>>
>>>>>> these bugs seems somehow related with what I've detected: proxy
>>>>>> resolution and broken references. The example I posted seems to
>>>>>> match both of those cases. However, I've got also some invalid
>>>>>> diffs over references to elements on the same model. As I have
>>>>>> said, these multivalued refences seemed equal when I take a look
>>>>>> at the XMI, so there most probable reason would problems during
>>>>>> proxy resolution.
>>>>>>
>>>>>> Curiously enough, these false triggering only appears if there is
>>>>>> at least 1 real difference in the model. If the models are
>>>>>> completely equal, no false differences are shown.
>>>>>>
>>>>>> I have a model with one only real difference that actually returns
>>>>>> like 45 false differences, all related with this problem.
>>>>>> Unfortunately, I cant provide it since its property of the company
>>>>>> I work for. All I have is this false triggering over some UMLX QVT
>>>>>> Core instances. I'll try to get these with some public metamodels
>>>>>> so I can send them to you.
>>>>>>
>>>>>> Cheers,
>>>>>> Víctor.
>>>>>>
>>>>>> laurent Goubet escribió:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We already have some bugs on references resolving, namely bugs
>>>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877 )
>>>>>>> and #229663 (
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>>>
>>>>>>> If the issue you encounter doesn't fit in those, could you create
>>>>>>> a new bug report with example models to reproduce this?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I've used EMF Compare with some models of mine, receiving some
>>>>>>>> false positives (sometime too much false positives). Those occur
>>>>>>>> only in multivalued EReferences that are apparently equal
>>>>>>>> (referenced values where equal). The only different thing from
>>>>>>>> other ERefereces of the same metamodel I've noticed is having no
>>>>>>>> EOpposite and containment=false.
>>>>>>>>
>>>>>>>> Take a look at these two models that generate a false positive
>>>>>>>> (using UMLX's QVT Core metamodel):
>>>>>>>>
>>>>>>>>
>>>>>>>> ########### Model 1 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ########### Model 2 #############
>>>>>>>>
>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>> <usedPackage
>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>
>>>>>>>> </modelParameter>
>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>
>>>>>>>> ####################################
>>>>>>>>
>>>>>>>> - The only differences' I've introduced is the nsURI of the root
>>>>>>>> node.
>>>>>>>>
>>>>>>>> EMF Compare shows correctly the changes on the nsURI, but also
>>>>>>>> changes on "usedPackage" EReference, indicating that
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>>>> has been
>>>>>>>> added on the first model, and deleted in the second one.
>>>>>>>>
>>>>>>>> I've been digging a little bit in the source code and noticed
>>>>>>>> what's going on.
>>>>>>>>
>>>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>>>
>>>>>>>> These four nodes are properly added to
>>>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>>>
>>>>>>>> The problem appears in
>>>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying to
>>>>>>>> retrieve from the map the matchModel of
>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>>>> sense, since that reference wasn't matched during first matching
>>>>>>>> phase).
>>>>>>>>
>>>>>>>>
>>>>>>>> So I guess there are two solutions:
>>>>>>>>
>>>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..." returns
>>>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate" method)
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send you
>>>>>>>> the example models and metamodel.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Víctor.
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619177 is a reply to message #125132] Thu, 05 June 2008 14:02 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050004070602070402010902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Thanks for that ;). The issue didn't come from the diff engine
(difference detection) but rather from the match engine (elements
mapping). the content of a derived containment difference doesn't appear
in the eobject's content list (EObject#eContents() /
EObject#eAllContents()) so we weren't able to match them and they were
detected as differences.

Ed, is this a bug in EMF or derived references weren't meant to appear
in the content list event when they are containment references?

Thanks for the feedback!

Laurent Goubet
Obeo

V
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619179 is a reply to message #125154] Thu, 05 June 2008 17:35 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31032
Registered: July 2009
Senior Member
Laurent,

The problem with a derived containment reference is that you can't
really derive a containment reference; Kenn ran into this issue with UML
as well with subset/superset features. The only scenario where EMF
supports such a thing directly is in the case where the feature derives
from the information in a feature map, and in that case, we ensure that
the contents derived from the feature map are properly included in the
right order where the feature map determines the order. Some of the
problems with trying to make this work are issues like the eContainer
must be consistent and in particular
x.eContainer().eGet(x.eContainmentFeature()) must return x or a list
containing x. So if the containment reference derives from another
containment reference, the containment feature isn't consistent. If the
containment reference derives from a non-containment reference, it's
hard to imagine that the eContainer will be correct. So it's likely
that there's something inconsistent about a model that has derived
containment features. The subject line talks about multi-valued
non-containment references which makes me think that the derivation is
perhaps done in a bad direction. I.e., while it's fine to derive a
non-containment reference from a containment reference, the other
direction doesn't work well at all.


laurent Goubet wrote:
> Thanks for that ;). The issue didn't come from the diff engine
> (difference detection) but rather from the match engine (elements
> mapping). the content of a derived containment difference doesn't
> appear in the eobject's content list (EObject#eContents() /
> EObject#eAllContents()) so we weren't able to match them and they were
> detected as differences.
>
> Ed, is this a bug in EMF or derived references weren't meant to appear
> in the content list event when they are containment references?
>
> Thanks for the feedback!
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Done :)
>>
>> Metamodel, genmodel, test instances and .emfdiff file.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=235606
>>
>> Cheers,
>> Víctor
>>
>> laurent Goubet escribió:
>>> Víctor,
>>>
>>> I can't seem to reproduce this bug with either setting I can put in
>>> a test metamodel :/. Could you provide us with a dummy metamodel
>>> presenting a reference producing this bug? Preferrably on bugzilla.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Víctor Roldán Betancort a écrit :
>>>> Laurent,
>>>>
>>>> I think I know why it's repored as a difference. As far As I've
>>>> seen in the source code, every element that's matched is put into a
>>>> hashmap (GenericDiffEngine.java:82 -> eObjectToMatch), linked with
>>>> a "match2element" structure. During differences analysis, anything
>>>> that is not inside that hashmap is considered a difference (check
>>>> "computeAddedReferences" and "computeDeletedReferences" methods).
>>>> Since you ignore derived elements, these won't appear in the hashmap.
>>>>
>>>> laurent Goubet escribió:
>>>>> Víctor,
>>>>>
>>>>> Ha, we indeed ignore derived references for comparison
>>>>> (GenericDiffEngine#shouldBeIgnored(EReference)) :
>>>>>
>>>>> /**
>>>>> * Determines if we should ignore a reference for diff detection.
>>>>> * <p>
>>>>> * Default is to ignore references marked either
>>>>> * <ul>
>>>>> * <li>Containment</li>
>>>>> * <li>Container</li>
>>>>> * <li>Transient</li>
>>>>> * <li>Derived</li>
>>>>> * </ul>
>>>>> * </p>
>>>>> * <p>
>>>>> * Clients should override this if they wish to ignore other
>>>>> references.
>>>>> * </p>
>>>>> *
>>>>> * @param reference
>>>>> * Reference to determine whether it should be
>>>>> ignored.
>>>>> * @return <code>True</code> if reference has to be ignored,
>>>>> <code>False</code> otherwise.
>>>>> */
>>>>> protected boolean shouldBeIgnored(EReference reference) {
>>>>> boolean ignore = reference.isContainment();
>>>>> ignore |= reference.isDerived();
>>>>> ignore |= reference.isTransient();
>>>>> ignore |= reference.isContainer();
>>>>> return ignore;
>>>>> }
>>>>>
>>>>> What I don't understand is ... if we ignore them, why are there
>>>>> differences reported on it? I wonder if this truly is the source
>>>>> of the issue but will look into it some more. Thanks for the
>>>>> feedback.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Víctor Roldán Betancort a écrit :
>>>>>> Hi Laurent,
>>>>>>
>>>>>> after 2 days searching, I found the source of the problem for
>>>>>> these false positives. And it's not about containment. It's about
>>>>>> the "derived" attribute of an EAttribute/EReference. In my case,
>>>>>> I had a derived EReference (it shouldn't be that way, actually),
>>>>>> which was also container. Any model element contained by this
>>>>>> "derived" EReference was ignored by the engine during the
>>>>>> matching. Is this a correct behaviour? Should I raise a bugzilla?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Víctor.
>>>>>>
>>>>>> laurent Goubet escribió:
>>>>>>> Víctor,
>>>>>>>
>>>>>>> Yes, if there isn't any real differences, the two files are
>>>>>>> exactly the same and compare won't go through the trouble of
>>>>>>> finding other comparators (such as EMF Compare) to try and find
>>>>>>> what has been changed.
>>>>>>>
>>>>>>> Having example models would indeed be the best for us to
>>>>>>> understand the actual issue. I can easily understand that having
>>>>>>> 1 difference triggerring 45 false positives is unexploitable.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>> Laurent,
>>>>>>>>
>>>>>>>> these bugs seems somehow related with what I've detected: proxy
>>>>>>>> resolution and broken references. The example I posted seems to
>>>>>>>> match both of those cases. However, I've got also some invalid
>>>>>>>> diffs over references to elements on the same model. As I have
>>>>>>>> said, these multivalued refences seemed equal when I take a
>>>>>>>> look at the XMI, so there most probable reason would problems
>>>>>>>> during proxy resolution.
>>>>>>>>
>>>>>>>> Curiously enough, these false triggering only appears if there
>>>>>>>> is at least 1 real difference in the model. If the models are
>>>>>>>> completely equal, no false differences are shown.
>>>>>>>>
>>>>>>>> I have a model with one only real difference that actually
>>>>>>>> returns like 45 false differences, all related with this
>>>>>>>> problem. Unfortunately, I cant provide it since its property of
>>>>>>>> the company I work for. All I have is this false triggering
>>>>>>>> over some UMLX QVT Core instances. I'll try to get these with
>>>>>>>> some public metamodels so I can send them to you.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Víctor.
>>>>>>>>
>>>>>>>> laurent Goubet escribió:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We already have some bugs on references resolving, namely bugs
>>>>>>>>> #199877 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=199877
>>>>>>>>> ) and #229663 (
>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=229663 ).
>>>>>>>>>
>>>>>>>>> If the issue you encounter doesn't fit in those, could you
>>>>>>>>> create a new bug report with example models to reproduce this?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Laurent Goubet
>>>>>>>>> Obeo
>>>>>>>>>
>>>>>>>>> Víctor Roldán Betancort a écrit :
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I've used EMF Compare with some models of mine, receiving
>>>>>>>>>> some false positives (sometime too much false positives).
>>>>>>>>>> Those occur only in multivalued EReferences that are
>>>>>>>>>> apparently equal (referenced values where equal). The only
>>>>>>>>>> different thing from other ERefereces of the same metamodel
>>>>>>>>>> I've noticed is having no EOpposite and containment=false.
>>>>>>>>>>
>>>>>>>>>> Take a look at these two models that generate a false
>>>>>>>>>> positive (using UMLX's QVT Core metamodel):
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ########### Model 1 #############
>>>>>>>>>>
>>>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>>>>> xmlns:eqvtbase="http://www.eclipse.org/gmt/umlx/EQVTbase"
>>>>>>>>>> xmi:id="ast0" name="umlRdbms" nsURI="umlRdbms"
>>>>>>>>>> nsPrefix="umlRdbms">
>>>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>>>> <usedPackage
>>>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>>>
>>>>>>>>>> </modelParameter>
>>>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>>>
>>>>>>>>>> ########### Model 2 #############
>>>>>>>>>>
>>>>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>>>>> <eqvtbase:Transformation xmi:version="2.0"
>>>>>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:eqvtbase="umlRdbms"
>>>>>>>>>> xmi:id="ast0" name="CHANGED" nsURI="test" nsPrefix="umlRdbms">
>>>>>>>>>> <modelParameter xmi:id="ast8" name="middle">
>>>>>>>>>> <usedPackage
>>>>>>>>>> href=" platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "/>
>>>>>>>>>>
>>>>>>>>>> </modelParameter>
>>>>>>>>>> </eqvtbase:Transformation>
>>>>>>>>>>
>>>>>>>>>> ####################################
>>>>>>>>>>
>>>>>>>>>> - The only differences' I've introduced is the nsURI of the
>>>>>>>>>> root node.
>>>>>>>>>>
>>>>>>>>>> EMF Compare shows correctly the changes on the nsURI, but
>>>>>>>>>> also changes on "usedPackage" EReference, indicating that
>>>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / "
>>>>>>>>>> has been
>>>>>>>>>> added on the first model, and deleted in the second one.
>>>>>>>>>>
>>>>>>>>>> I've been digging a little bit in the source code and noticed
>>>>>>>>>> what's going on.
>>>>>>>>>>
>>>>>>>>>> - Root node is marked as not equal (similarity = 0.6....)
>>>>>>>>>> - Typed model node is marked as equal (similarity = 1.0)
>>>>>>>>>>
>>>>>>>>>> These four nodes are properly added to
>>>>>>>>>> "GenericDiffEngine::eObjectToMatch" hashMap.
>>>>>>>>>>
>>>>>>>>>> The problem appears in
>>>>>>>>>> "GenericDiffEngine::computeAddedReferences" and
>>>>>>>>>> "GenericDiffEngine::computeDeletedReferences", while trying
>>>>>>>>>> to retrieve from the map the matchModel of
>>>>>>>>>> " platform:/resource/com.foo.org/models_ecore/TumlRdbms.ecore# / ",
>>>>>>>>>> which doesn't actually exist in "eObjectToMatch" (what makes
>>>>>>>>>> sense, since that reference wasn't matched during first
>>>>>>>>>> matching phase).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So I guess there are two solutions:
>>>>>>>>>>
>>>>>>>>>> - Add these referenced resources to "eObjectToMatch"
>>>>>>>>>> - Filtering what "(List<EObject>)EFactory.eGetAsList..."
>>>>>>>>>> returns
>>>>>>>>>> ("GenericDiffEngine::createNonConflictingReferencesUpdate"
>>>>>>>>>> method)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm sorry if I haven't been clear. If necessary, I'll send
>>>>>>>>>> you the example models and metamodel.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Víctor.
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] False positives on multivalued EReferences with containment=false [message #619193 is a reply to message #125160] Fri, 06 June 2008 07:32 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090109060409090606050500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

Yes, I can understand the problem with such references. And As V
Previous Topic:[EMF Compare] is the javadoc broken?
Next Topic:[Announce] EMF Teneo Builds
Goto Forum:
  


Current Time: Sat Apr 04 19:39:03 GMT 2020

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

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

Back to the top