Community
Participate
Working Groups
Currently two IObjectMatcher implementations exist: - IdentifierEObjectMacher, which looks at EObject ID's - ProximityEObjectMatcher, which uses a distance function Besides the global ID's (used by IdentifierEObjectMacher), and the default fragment paths (used by ProximityEObjectMatcher), as of EMF 2.3 reference keys can be used to identify objects uniquely, see Chapter 21.3.2 of the EMF book. There should be an IObjectMatcher what uses EKeys to identify objects uniquely. Note that, probably the ProximityEObjectMatcher does take EKeys into account, by calling 'matchingURIs' inside the EditionDistance class.
Hello Rolf, Do you have a use-case where the fact that EMFCompare does not provide an implementation of IEObjectMatcher that uses EKeys to identify EObjects is a problem? Because, as you mention, ProximityEObjectMatcher will use EKeys (via the URI), and fall back to heuristics of no EKey is present.
Hello Laurent, We (try to) define unique identifiers for each element in our models. These id's are either based on global ids or on tags on containment references on objects that are already uniquely identifiable. Similar matching behavior is expected for all uniquely identifiable objects. When using the IdentifierEObject matcher, objects are only matched when the ID's are the same, there is no fallback to the ProximityEObjectMacher for objects that have an ID defined. For uniquely identifiable objects by tags similar behavior is expected. If tags are defined, only use tags and do not fall back to Proximity. Currently when the proximity matcher is used, and tags do not match, other heuristics are used instead of marking it as not matching. Furthermore, for large models this fallback to other heuristics has huge performance impact.
