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-235 controller <p>With binding aware APIs, it is a common mistake to write an object into a particular point in the list (e.g. identifier with a target key), but fail to attach that key into the DTO being stored there.</p> <p>Given that the datastore has both data points, it can trivially correct for this mistake, allowing it to continue instead of producing a hard error.</p> <p>Implement this recovery strategy, along with a <b>very</b> stern LOG.warn(), which will detail the entry which was being written and the call stack where the transaction was allocated.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-235

DataStore should be able to handle missing keys in writes

Improvement Resolved Won't Do Tony Tkacik Robert Varga Thu, 27 Mar 2014 01:42:04 +0000 Tue, 25 Jul 2023 08:23:17 +0000 Tue, 9 Sep 2014 09:13:49 +0000 mdsal 0 3 <p>(In reply to Robert Varga from comment #0)<br/> &gt; With binding aware APIs, it is a common mistake to write an object into a<br/> &gt; particular point in the list (e.g. identifier with a target key), but fail<br/> &gt; to attach that key into the DTO being stored there.<br/> &gt; <br/> &gt; Given that the datastore has both data points, it can trivially correct for<br/> &gt; this mistake, allowing it to continue instead of producing a hard error.<br/> &gt; <br/> &gt; Implement this recovery strategy, along with a <b>very</b> stern LOG.warn(),<br/> &gt; which will detail the entry which was being written and the call stack where<br/> &gt; the transaction was allocated.</p> <p>Just want to make sure I understand the bug correctly. When utilizing the data store and putting an object into the tree (config or operational) the Node has an ID that should be identical to the location in the tree in which it is being placed. In some cases, the node is created without this ID, but when doing the write transaction since the code has both the ID and the node it can effectively WARN and proceed by setting the implied identifier in the Node. It this an accurate characterization? </p> <p>Assuming the characterization is correct and assuming that differing data stores can be implemented it would be best to implement this before control gets to a specific implementation.</p> <p>Correct. By „data store“ I really meant one of the binding-aware components, for example the BI connector, which is in the sweetspot for this kind of thing:</p> <p>It already generates BI data, so adding a few additional leaves should not have a major impact.</p> Development External issue ID 597 External issue URL Rank 0|i02j5b: