[MDSAL-422] DataObjectModification.getModificationType() throws ISE on UNMODIFIED Created: 08/Feb/19 Updated: 19/Mar/19 Resolved: 19/Mar/19 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding runtime |
| Affects Version/s: | Fluorine SR2, 3.0.6 |
| Fix Version/s: | Fluorine SR3, 3.0.7 |
| Type: | Bug | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
This problem is handled by OVSDB's TransactCommandAggregator, which explicitly catches the ISE generated by DataObjectModification.getModificationType(). The ISE is generated because modified children of a SUBTREE_MODIFIED node include a MERGE operation which turned out to be an UNMODIFIED node – which Binding cannot map, as it has only DELETE/WRITE/SUBTREE_MODIFIED options. Direct users usually handle this gracefully by ignoring the unmodified node when iterating over the nodes – but Binding would have to always filter modified nodes. This poses an interesting lifecycle problem: the node should really be pruned from the DataTreeCandidate, so that if this is the only modification within a SUBTREE_MODIFIED parent, that parent would turn into UNMODIFIED, and cascade upwards.
|
| Comments |
| Comment by Robert Varga [ 11/Feb/19 ] |
|
Testing with current 2.1.9-SNAPSHOT, the problem is that multiple child nodes are being modified, hence the change will not be completely squashed, i.e. it will contain a both UNMODIFIED and WRITE children. I think the problem is the getModifiedChild() contract, which specifies null return "if child was not modified / does not exists". RecursiveUnmodifiedCandidateNode is in direct violation of this contract, as it will actively allow descent into child nodes, pretending all of them are unmodified.
|
| Comment by Robert Varga [ 11/Feb/19 ] |
|
We also do not check for these nodes in AbstractModifiedNodeBasedCandidateNode, and expose them through both getChildNodes() and getModifiedChild(). I think the best approach is to fix the issue in MDSAL/Controller and clarify the API contract in 3.0.0. |