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/CONTROLLER-1909 controller <p>This is a follow-up on <a href="https://jira.opendaylight.org/browse/CONTROLLER-1908" title="Deduplicate NodeIdentifierWithPredicate/LeafNode values from incoming streams" class="issue-link" data-issue-key="CONTROLLER-1908"><del>CONTROLLER-1908</del></a>, where we should understand where a LeafNode inside a MapNode corresponds to a key and thus has had its value emitted as part of the NodeIdentifierWithPredicates – these are expected to always match.</p> <p>While <a href="https://jira.opendaylight.org/browse/CONTROLLER-1908" title="Deduplicate NodeIdentifierWithPredicate/LeafNode values from incoming streams" class="issue-link" data-issue-key="CONTROLLER-1908"><del>CONTROLLER-1908</del></a> deals with the memory footprint of data restored from the stream, this issue is about not emitting duplicate values (or even QNames) for leaves that are covered in the predicates.</p> <p> </p> CONTROLLER-1909

Deduplicate NodeIdentifierWithPredicate/LeafNode values when writing streams

Improvement Medium Resolved Done Robert Varga Robert Varga Mon, 26 Aug 2019 19:44:39 +0000 Fri, 21 Feb 2020 05:12:15 +0000 Fri, 21 Feb 2020 05:12:03 +0000 Magnesium clustering 0 2 <p>There are really two basic ways to approach this:</p> <ul> <li>emit NodeIdentifierWithPredicates as usual, deduplicate leaf values (perhaps with dedicated 'key leaf' item type)</li> <li>emit leaf values (i.e. the entire MapNode first and then write out the QNames of keys</li> </ul> <p>or perhaps some hybrid approach.</p> <p>For leaf-lists the, storing is quite clear – we do not need to emit values twice, no matter what – but they are not as common as MapNodes</p> <p>This has been implemented as part of <a href="https://jira.opendaylight.org/browse/CONTROLLER-1919" title="Add Magnesium streaming format" class="issue-link" data-issue-key="CONTROLLER-1919"><del>CONTROLLER-1919</del></a></p> Blocks CONTROLLER-1908 Duplicate CONTROLLER-1919 Development Rank 0|i03oqf: