| Default Behaviour for matching derived features [message #1746365] |
Thu, 27 October 2016 14:04  |
 Conor O'Mahony
Messages: 27
Registered: August 2016 |
Junior Member |
|
|
In my ecore model, I have a "Block" class and an "Input" class, where the Block class has a reference feature "inputs", which is a list of Inputs.
The reference doesn't contain all the Inputs we want to compare using EMF compare, (in our application we query another model object "BlockType" to gather the full list of Inputs for that Block).
Essentially I want to compare all relevant Inputs for a Block, so I added another derived, transient, volatile feature to the ecore model - "derivedInputs", where the getDerivedInputs() method implementation returns a list of Inputs, the ones contained on the Block object itself and the extra ones from the BlockType object.
For the EMF compare, I extend DefaultDiffEngine, and override createFeatureFilter() method to return a FeatureFilter, which in turn implements isIngnoredReference() to ignore the original BLOCK_INPUTS feature and to NOT ignore the derived feature BLOCK_DERIVED_INPUTS,
This seems to work fine for differencing - when two blocks are matched and being diffed it shows the Derived Inputs differences, but it seem to be missing a step that matches these Derived Inputs to begin with, it looks like they are not considered in the matching engine. I have my own IdentifierEObjectMatcher class with a custom ID function, which was returning an ID for Input objects but this is no longer being called for the Derived Inputs -
Is there a step that I am missing to include the derived feature in the scope of the matching as well?
Many thanks,
Conor
|
|
|
| Re: Default Behaviour for matching derived features [message #1746628 is a reply to message #1746365] |
Wed, 02 November 2016 09:13  |
|
Hi,
We match elements by iterating over the content of the resources, using plain emf for the iteration (EcoreUtils.getAllProperContents(...)). If your blocks are not part of that iteration, they will not be matched. You might want to take a look at what's done in org.eclipse.emf.compare.scope.FilterComparisonScope.getCoveredEObjects(Resource) and see if we properly iterate over all of your objects. If not, you will have to implement your own comparisonScope to change the way we iterate over objects in your case in order to include the derived blocks.
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.03641 seconds
] 
Search
Help
Register
Login
Home
