Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Create a list node (add multiple children) under existing parent node;
    adding a list with a single value is already supported
  • Delete a list node – removing all the data nodes which belong to specified list node;
    current implementation allows only removal one entry per request; fill full xpath to node is required
  • Replace a list node – the operation which is a combination of delete then create operations
    described above

It's an assumption the list node cannot be a root level element, so the parent data node is always expected

...

.

Single node vs multiple nodes

Data parsing context

On data conversion from String to DataNode object there is an intermediate stage of data being represented as 
a NormalizedNode instance which is a Yang Tools library artifact.

The NormalizedNode represents the list node element as a single object. It means the data fragment which
represents the list element with multiple entries can be successfully converted into NormalizedNode.

However the subsequent NormalizedNode to DataNode conversion performed by CPS internal logic supports only
single DataNode object as top level element. The functionality of DataNodeBuilder require to be extended 
in order to convert the list element data (fragment) into collection of DataNode objects

Same API/SPI usage context

In current implementation all the non-read operations are taking as input single data node.

In order to support multiple data nodes as input it requires either  an existing methods signature update
or new methods which will serve list data node.

Below is an example of SPI method signatures update in order to support backward compatibility

Code Block
languagejava
// before

void addChildDataNode(@NonNull String dataspaceName, @NonNull String anchorName, @NonNull String parentXpath,
        @NonNull DataNode dataNode);

void replaceDataNodeTree(@NonNull String dataspaceName, @NonNull String anchorName, @NonNull DataNode dataNode);	

// after

void addChildDataNode(@NonNull String dataspaceName, @NonNull String anchorName, @NonNull String parentXpath,
        @NonNull DataNode ... dataNode);

void replaceDataNodeTree(@NonNull String dataspaceName, @NonNull String anchorName, @NonNull DataNode ... dataNode);

cons: despite usage of same methods the actual logic for processing single node significantly differs from the one 
which is required to process multiple data nodes, with taking into account the caller logic also requires update 
the benefit of this approach is negligible.

Suggestion is to provide

Same REST API usage context



Proposal