...
It's an assumption the list node cannot be a root level element, so the parent data node is always expected.
Addressing the List Node
TBD
Single node vs multiple nodes
...
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
createdCreated: Jira server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-358
...
Code Block | ||
---|---|---|
| ||
// 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 , as result
- the logic split will be required within a method itself, adding complexity to both the implementation
and the testing - the invocation logic requires to be updated as well, causing extra complexity to caller logic as well
While benefit of this approach is negligible .Suggestion the suggestion is to provide separate API/SPI methods for operations with list-node elements.
Same REST API usage context
Using same REST API also seems not reasonable.
As example there is a replace (PUT) operation for a data fragment with following inputs (excluding dataspace and anchor):
- parent node xpath
- data fragment as JSON
Code Block |
---|
// xpath=/test-tree
// request body:
{
"branch": {[
"name": "Branch",
"nest": {
"name": "Nest"
}
]}
} |
The case became uncertain because it's unclear what the action is expected exactly:
- replace an existing data node with xpath /test-tree/branch[@name='Branch']
or throw an exception if record with such xpath does not exist - replace the list node content (assumes all prior entries removal) with provided data
so there should be additional parameter to clarify which exact behavior is requested.
Any additional parameter (even optional one) leads to API/SPI for service level to be modified
in order to handle this extra parameter. It also leads to logic complication as described above.
From client perspective the additional parameter is same impact/effort as new entry point.
Suggested new entry points to be used for list-nodes only like below
/dataspaces/{dataspaceName}/anchor/{anchorName}/list-node
Implementation Proposal
Proposal