|The changeRecorder consolidateChanges does not seem to handle opposite features [message #1748370]
||Tue, 22 November 2016 14:31
|| Florian Barbin
Registered: August 2010
In Sirius we have a DNode.outgoingEdges feature which is the opposite of DEdge.sourceNode feature. That is the same with DNode.incomingEdges and DEdge.targetNode.
We have a situation where a DEdge can be created and removed in a same transaction. Those actions are performed by recordingCommands.
In short, the state before the transaction is DNode.outgoingEdges = empty and the DEdge does not exist. After the transaction, DNode.outgoingEdges is still empty and the DEdge is properly detached from its parent.
But performing an undo leads to this state:
DNode.outgoingEdges references the DEdge created before, the DEdge.sourceNode references the DNode but the DEdge is still detached from its parent.
Indeed, the first time we created the DEdge and called DEdge.setSourceNode(DNode), the TransactionChangeRecorder has created a FeatureChange based on DNode.outgoingEdges (the opposite) with value = empty list.
Next, the DEdge cross references are removed (EcoreUtil.remove(setting, eObject)) and finally the DEdge is removed (EcoreUtil.remove(eObject)). But this time, the TransactionChangeRecorder has created a FeatureChange based on DEdge.sourceNode with value = DNode.
During the consolidation (org.eclipse.emf.ecore.change.util.BasicChangeRecorder.consolidateChanges()) the eliminateEmptyChanges method removes the DNode.outgoingEdges featureChange since the value is the same than the current state.
At the end of the consolidation, only DEdge.sourceNode remains with value = DNode. That explains the undo behavior.
Does this look like a bug in the EMF ChangeRecorder or do we missed something to handle this case ?
I will make a junit test based on ecore and attach it to a bugzilla if needed.
Powered by FUDForum
. Page generated in 0.02237 seconds