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-246 mdsal <p>Add method which creates data if data does not already exists, otherwise throws error.</p> <p>RFC: <a href="https://tools.ietf.org/html/rfc6241#page-38" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#page-38</a> part about create method</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-246

Re-align data interaction model with RFCs 6241/8040/8072

Epic High Confirmed Unresolved Unassigned Ivan Hrasko pt Fri, 21 Apr 2017 10:50:15 +0000 Tue, 9 Jan 2024 09:05:54 +0000 14.0.0 Binding API DOM API 0 2 <p>This is follow up issue of <a href="https://bugs.opendaylight.org/show_bug.cgi?id=7868" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7868</a></p> <p>RFC 8040 defines the set of operations which we need to provide on the northbound. This notably includes more operations and the ietf-yang-patch model, which we should support in binding.</p> <p>While most functionality can be provided by RESTCONF using emulation, which works reasonably well in local node scenarios, it is very clunky and error-prone.</p> <p>In clustered scenarios the emulation layer needs to perform multiple operations, typicaly exists(), followed by puts(), which is inefficient as it:</p> <ul class="alternate" type="square"> <li>adds 'read' aspect to otherwise write-only transactions</li> <li>incurs multiple messages</li> </ul> <p>Hence providing native support to these operations will provide significant performance benefits.</p> <p>ietf-yang-patch defines effectively a DSL for expressing data store transformations, hence the set of operations we can provide to the end user (via DOM and Binding APIs) will vastly expand.</p> <p>This is gaining criticality, as users are increasing using user-ordered lists, which require insert/point support as hinted in NETCONF WG RFCs.</p> <p>The write side of APIs need to realigned with RFC 8072, which defines the following operations:</p> <p>RFC ReadWriteTransaction equivalent<br/> === ===============================<br/> CREATE exists() + put()<br/> DELETE exists() + delete()<br/> INSERT read() + put()<br/> MERGE merge()<br/> MOVE read() + put()<br/> REPLACE put()<br/> REMOVE delete()</p> <p>Furthermore <a href="https://tools.ietf.org/html/rfc8040#section-4.5" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc8040#section-4.5</a> requires REPLACE operation to indicate whether a new item was created or a previous one was replaced. This use case can be supported via invoking an exists() operation before the modification, recording its (future) result &#8211; and relying on transaction isolation/reconciliation to throw OptimisticLockFailedException.</p> <p>The read side of APIs really just need to support depth/fields requests. Since this data access pattern would result in partial subtrees being reported, I think we can forgo that optimization for now and perform filtering in the NETCONF/RESTCONF components.</p> <p><a href="https://tools.ietf.org/html/rfc6241#section-6" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#section-6</a> additionally specifies subtree filtering capabilities, which are probably best served via (an optional) XPath evaluation engine.</p> <p>Robert, for now I'm assigning this to you.</p> <p>Please decide if it should be moved to someone else.</p> <p>This one is on the backlog – we don't assign issues until someone actively is going to work on them.</p> <p>We certainly want to use RFC8072 yang-data objects for modeling binding-api requests.</p> <p>At DOM we probably want to go dual mode: based on NormalizedNode and API-driven, with a friendly Java API. If that is the case, one of those should be just a default method overlay in interfaces.</p> Blocks NETCONF-474 NETCONF-257 Duplicate CONTROLLER-1639 Development Epic Name MD-SAL patch External issue ID 8272 External issue URL Issue Type Rank 0|i02x7r: