[CONTROLLER-1639] Add a create() method Created: 21/Apr/17  Updated: 25/Jul/23  Resolved: 14/Nov/18

Status: Resolved
Project: controller
Component/s: clustering
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Ivan Hrasko Assignee: Unassigned
Resolution: Duplicate 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
blocks NETCONF-257 Improvement of code by remove read op... Resolved
Duplicate
is duplicated by MDSAL-246 Re-align data interaction model with ... Confirmed
External issue ID: 8271

 Description   

Add method which creates data if data does not already exists, otherwise throws error.

RFC: https://tools.ietf.org/html/rfc6241#page-38 part about create method



 Comments   
Comment by Ivan Hrasko [ 21/Apr/17 ]

This is follow up issue of https://bugs.opendaylight.org/show_bug.cgi?id=7868

Comment by Tom Pantelis [ 26/Apr/17 ]

Can you explain more the purpose of this bug? Is this actually related to clustering (you reference an RFC but that's related to netconf)?

Comment by Ivan Hrasko [ 28/Apr/17 ]

We just need create(YangInstanceIdentifier, NormalizedNode) method in transactions
to be able to implement POST method in Restconf (thats why reference to netconf RFC).

Now we use exists(YangInstanceIdentifier) and put(YangInstanceIdentifier, NormalizedNode) methods to simulate POST. Check for existence and create data if does not already exists.

It would by more efficient to have just one create(YangInstanceIdentifier, NormalizedNode) method which will do it.

I dont think it is related to clustering.

Comment by Robert Varga [ 28/Apr/17 ]

The issue is more general, as there are other operations which make sense in a clustered setting (like remove vs. delete). Some can be emulated by a prior exist() check, but that does hurt performance.

At any rate, this will require an update to the FE/BE protocol, hence the clustering tag.

Generated at Wed Feb 07 19:56:04 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.