Skip to main content


Eclipse Community Forums

      Home
Home » Modeling » Compare » New UUIDs for non-conflicting Addition changes after merge
New UUIDs for non-conflicting Addition changes after merge [message #1751682] Thu, 12 January 2017 08:12 Go to next message
Eclipse UserFriend
Hi!

I am using EMF Compare to handle model merging in my own EMF-based application and I have encountered a problem when merging.

The use case I've been looking at is the following:
1. A model has local changes (conflicting or non-conflicting) and the user tries to merge some changes from the remote
2. Before starting the merge we commit all local changes and start the merge process (using the JGit MergeCommand for each commit coming from the remote)

The problem appears in the resulted model after the merge process has finished.
It seems like all changes introducing new eContainment references result in new objects with new UUIDs locally and not in a copy of the objects from the remote as expected. This is, of course, not at all desirable in our application since we use UUIDs to identify objects and this will highly influence future merges and the entire collaboration process.

Do you have any ideas where could the problem arise from?

Re: New UUIDs for non-conflicting Addition changes after merge [message #1751733 is a reply to message #1751682] Fri, 13 January 2017 04:08 Go to previous messageGo to next message
Eclipse UserFriend
Hi Monica,

This sounds like EMF Compare isn't using your IDs at all. Have you tried removing the unknowns here by comparing and merging your models directly from a standard eclipse to see if your UUIDs were preserved that way? If they are not preserved even through the normal operation (no git involved, just compare two models with each other) then EMF Compare probably doesn't manage to see your IDs (or you are computing them in a non standard way?).

Please try and check what's done within org.eclipse.emf.compare.merge.ReferenceChangeMerger.addInTarget(ReferenceChange, boolean) in your case. If we can't properly copy the UUID, this is the most likely culprit. If there is a bug please track it on bugzilla with reproduction steps so that we can check from our side.

Laurent Goubet
Obeo
Re: New UUIDs for non-conflicting Addition changes after merge [message #1751761 is a reply to message #1751733] Fri, 13 January 2017 10:15 Go to previous messageGo to next message
Eclipse UserFriend
Hi again, Laurent and thank you for the reply!

I tried comparing our models using the normal operation in eclipse (no git involved) and the result was that after merging the new object had no UUID.

Just to be a bit more specific here: in our models, the UUID is an EString attribute that we have defined to be unique and which we do generate using the EcoreUtil.generateUUID() method. In addition, we've overwritten the DefaultRCPMatchEngineFactory so that the matcher uses our own idComputation function. Having all this in mind perhaps you are right and we are computing UUIDs in a "non standard way".

However, it actually helped a lot looking into the ReferenceChangeMerger, specifically in the createCopy() function, since it did seem like the problem emerged there. What we've done as a solution, for now, is we've overwritten this method in a class of our own and after the copy process of the super is done we simply set the UUID of the copied object to the UUID of the reference object.

Monica
Re: New UUIDs for non-conflicting Addition changes after merge [message #1751765 is a reply to message #1751761] Fri, 13 January 2017 10:45 Go to previous messageGo to next message
Eclipse UserFriend
It sounds to me like you consider in your business rules that this attribute is the object's id... but that fact is not modelized (the attribute is not marked as being an id) and not xmi:id either.

This wouldn't be handled by EMF Compare itself since we're only applying "generic" rules in the implementation; rules that can be applied to all models. xmi:id (the ids that you can defined in an xmi resource) and id attributes (EAttributes that are considered as identifiers by EMF) are generic and handled, but what you're described doesn't look like it. What I believe should happen in your case is that EMF Compare should see the changes you make to your ids as regular attribute changes, that you thus have to accept as well in order to have the same id on both side. This will not be the case if your id is set as "derived" or is not part of the attributes compared (they're filtered out by the FeatureFilter).

Please tell me if the assumptions I make above are wrong, but if they are true, yes, I think what you've done through defining your own merger that will take care of copying the uuid is the best course of action.

Laurent Goubet
Obeo
Re: New UUIDs for non-conflicting Addition changes after merge [message #1751853 is a reply to message #1751765] Mon, 16 January 2017 04:48 Go to previous messageGo to next message
Eclipse UserFriend
Most of your assumptions are correct, Laurent! It is true that our "uuid" attribute is set as "derived" so that is the reason why EMF Compare does not see the changes on it. However, the attribute is actually marked as being an ID in the ecore so in that sense it is modelized. In addition, all references between objects in our application use this "uuid" attribute. Could there be something else wrong, perhaps another property that makes our attribute not fall within the "generic" rules?

These are all the properties of our "uuid" attribute:

    Changeable true
    Derived true
    EAttribute Type EString[java.lang.String]
    EType EString[java.lang.String]
    ID true
    Lower Bound 1
    Name uuid
    Ordered true
    Transient false
    Unique true
    Unsettable false
    Upper Bound 1
    Volatile false


The attribute also has an EAnnotation (source: http://www.eclipse.org/emf/2002/GenModel; key: suppressedSetVisibility; value: true.)

We will move forward with our own merger for now, as it seems to solve the problem and perhaps consider the impact of introducing xmi:id.
Re: New UUIDs for non-conflicting Addition changes after merge [message #1751958 is a reply to message #1751853] Tue, 17 January 2017 03:43 Go to previous message
Eclipse UserFriend
Hi Monica,

The one rule that overrides them all is that your eattribute is marked as "derived". These will never be considered in the comparison since their values are computed. I am not sure what the implications would be, but you can try and override the FeatureFilter so that it doesn't ignore that particular derived attribute in your case.

Laurent Goubet
Obeo
Previous Topic:Adding extra nodes to the Content Merge Viewer
Next Topic:Left and Right panels disposed during conflict resolution
Goto Forum:
  


Current Time: Wed Jul 23 15:44:15 EDT 2025

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly