[YANGTOOLS-501] DataTree: lazy merge operations Created: 11/Sep/15  Updated: 10/Apr/22  Resolved: 25/Jan/16

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
is blocked by YANGTOOLS-500 DataTree: write/write/merge combo may... Resolved

 Description   

While implementing BUG-1258, we have reduced the amount of DataTrees we instantiate for write operations. Merge operations still assume full materialization of nodes, which is inefficient from the perspective of the work done and also leads to needless memory overhead in situations where LazyContainerNode could be used.



 Comments   
Comment by Robert Varga [ 11/Sep/15 ]

Resolving this issue requires centralizing state transition management inside

Comment by Robert Varga [ 11/Sep/15 ]

Resolving this issue requires centralizing state transition management inside ModifiedNode such that the the tree retains temporal ordering in the sense that the child nodes are always applied on top of the results of its ancestors.

SchemaAwareApplyOperation's handling of container merges currently assumes full materialization has already happened. This is not a fair assumption, as previous processing stages do not know against what data tree state the modification will be applied – hence their only reasonable option is to perform minimal materialization required to maintain the ModifiedNode contract.

SchemaAwareApplyOperation then needs to finish instantiation of ModifiedNode tree such that the resulting DataTreeCandidate holds an accurate delta.

Comment by Robert Varga [ 14/Sep/15 ]

https://git.opendaylight.org/gerrit/26853

Comment by Colin Dixon [ 19/Jan/16 ]

Patch on stable/beryllium: https://git.opendaylight.org/gerrit/#/c/32752/

Generated at Wed Feb 07 20:53:26 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.