https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-420 mdsal <p>When an InMemoryDataTree node appears/disappears, we report the appropriate APPEARED/DISAPPEARED event, which is sufficient for most users.</p> <p>Unfortunately, this breaks if the user attempts to drill into the modification, such as binding lookup of a container within a choice statement.</p> MDSAL-420

LazyDataObjectModification reports incorrect results

Bug High Resolved Duplicate Robert Varga Robert Varga Mon, 28 Jan 2019 18:30:54 +0000 Mon, 28 Jan 2019 23:42:48 +0000 Mon, 28 Jan 2019 23:42:23 +0000 Binding runtime 0 1 <p>Unfortunately the API contracts around here are fuzzy and untested, hence we are between a rock and a hard place. For direct users of DataTreeCandidateNode the current behavior makes sense. They know the node has appeared and if they choose to drill down, they will find the cause of the node's appearance, and this will be consistent with getChildNodes().</p> <p>We could simply flip the reporting to the WRITE/DELETE codepath, but that would end up being inconsistent with getChildNodes() as well as create further problems with the type of descendant nodes – for example if we have two nested non-presence containers, they both should be reported as APPEARED when a leaf in the inner container is introduced. Changing the logic would pretend the inner container was actually written, which is the wrong outcome.</p> <p>Hence it is up to Binding to deal with this difference and project a correct interpretation of the results. It certainly has all the tools required for the job.</p> <p>This has been observed when LazyDataObjectModification.getModifiedChild() is asked to cross an BindingStructuralType.INVISIBLE_CONTAINER node disappearing. Current code assumes 1:1 correspondence with DOM model, which is wrong.</p> <p>Since we are not reporting INVISIBLE_CONTAINERs, only their content, and we have a simplified ModificationType, which can only express WRITE/DELETE/SUBTREE_MODIFIED, we must treat a disappeared INVISIBLE_CONTAINER as a DELETE operation of all its children – i.e. not rely on DOM to provide correct answers here.</p> <p>This is a side-effect of <a href="https://jira.opendaylight.org/browse/YANGTOOLS-938" title="InMemoryDataStore delete/write cycle produces unexpected result" class="issue-link" data-issue-key="YANGTOOLS-938"><del>YANGTOOLS-938</del></a> and should be fixed there. With it applied, empty writes and deletes end up being DELETE modification types, hence making this a non-issue.</p> Duplicate YANGTOOLS-938 Development Rank 0|i03mdb: