Get operation should return all the data trees under the root when xpath is set to "/"
after discussion with Toine Siebelink it was decided to give priority to the GET operation first, before heading for other API's. A discussion with the architects is to be scheduled to discuss upon the following points:
should a separate end point be created which returns all the data trees under the root node
impact of ongoing versioning issue with CPS on the above point and backwards compatibility
after discussion with the architects it was decided to have a v2 of the GET API and the v2 will return all the data nodes in an array
The remaining CPS core API's might require modification with respect to decisions made for the GET operation. Based upon the decisions for the above Issue this table will be updated from time to time.
in the meeting it was decided to focus on GET operation first as the work on remaining API's seemed different from the one for the GET API. Also it was decided to first have a discussion with the architects regarding the GET API and then have a separate discussion for the remaining API;s
To implement V2 of Get Data Node API
New API to return all data nodes when xPath is set to root.
Existing functionality to be used when existing xPath is queried
should GET Data Node return a JSON array or JSON object in response for multiple data trees
as discussed in weekly meeting, it was decided that v2 of the GET API will return JSON Array and v1 will remain as is (that is returns single data node as JSON Object)
Update data node had inconsistencies where, updating leaf nodes for multiple container nodes would throw unexpected error.
And updating multiple list items in a list data node would cause partial update operation
After presenting the findings for patch operation and as per discussion in CPS sub team daily call, it was concluded that support for Patch operation for multiple data nodes would solve the inconsistencies found in the existing Patch operation.
Support for Patch for multiple data nodes to be implemented.
List of impacted API's
Operation
API
Issues
Possible Solution
GET
Anchor
getNode
getNode
Get a Node
should return all the data trees when xpath is set to root(/)
currently returns only the first data tree
modify the existing code for Get a Node API so it returns a List of fragment entities
this impacts other API's as well which make use of the Get operation
a separate API can be developed to return all the data trees, similar to Get all anchors and Get one anchor API in CPS
PUT
Anchor
remainingAPI
remainingAPI
Replace a node with descendants
Replace list content
No issues were found in Delete DataNode API
Following tests were performed
replacing multiple Data Nodes under one container node
replacing multiple Data Nodes under multiple container nodes (under root node xpath)
DELETE
Delete a datanode
No issues were found in Delete DataNode API
Following tests were performed:
Individual data nodes were deleted and the ones not deleted were retrieved successfully
When all data trees are deleted individually, the entire data node gets deleted from the DB eventually, i.e. an empty collection is not left behind when all data trees are deleted individually
When deleting using root node xpath, all container nodes are deleted.
PATCH
Anchor
patchAPI
patchAPI
Update node leaves
When the Patch operation is performed with xPath set to root node "/", then leaf value in all the modified data trees must be updated
Currently when updating container nodes using root node xPath, only the first data tree gets updated.
A detailed study on inconsistencies with Patch operation was documented in the following pages:
Update node API should support Patch operation for multiple data nodes.
Patch operation should allow user to update multiple leaf nodes for multiple container/list data nodes.
currently when the replace action is performed with xpath set to root, it will first perform a get operation internally to retrieve the first data tree and then execute the replace operation
but with support for multiple data trees under root
when the API is called with xpath set to "/", it will first get all the data trees
once all the data trees are returned the PUT operation will be performed
if xpath is set to "/" and the number of data trees on which the replace operation is being performed is less than the total number of data trees the operation of retrieving all the data trees does not seems to be feasible
when xpath is set to "/" the replace operation can return an error message
the user can specify the data tree for which Replace operation is to be performed,
but if the number of data trees on which replace operation is to be performed is significantly high
DELETE
Delete a datanode
when delete operation is performed with xpath set to root all the data trees must be deleted
PATCH
Update node leaves
when the API is called and xpath is set to "/", first the get operation is executed internally to retrieve all the data trees
once all the data trees are returned in a List the API proceeds to perform the Patch operation
if xpath is set to "/" and the number of data trees on which the patch operation is being performed is less than the total number of data trees the operation of retrieving all the data trees is not feasible
when xpath is set to "/" the patch operation can return an error message
the user can specify the data tree for which patch operation is to be performed, but the drawback of this approach is, when the number of data trees on which patch operation is to be performed is significantly big
POST
Add list element to existing list
when the API is called and xpath is set to "/", first the get operation is executed internally to retrieve all the data trees
once all the data trees are returned in a List the API proceeds to perform the Post operation
retrieving all the data trees does not seems feasible with xpath set to root, given the scenario where new list element is getting added to few of the data trees
with xpath set to root, the API should return an error message
the POST operation can be performed on particular data trees by specifying their respective xpaths.
The existing GET operation
Code Block
//Returns single fragment entity
default FragmentEntity findFirstRootByDataspaceAndAnchor(@NonNull DataspaceEntity dataspaceEntity,
@NonNull AnchorEntity anchorEntity) {
return findRootsByDataspaceAndAnchor(dataspaceEntity.getId(), anchorEntity.getId()).stream().findFirst()
.orElseThrow(() -> new DataNodeNotFoundException(dataspaceEntity.getName(), anchorEntity.getName()));
The updated GET operation is as follows to retrieve all the data trees under root
...
No issues were detected in Add list element API. The following tests were performed
Adding a single list item to existing list in DB
Adding multiple list items to existing list in DB
The list items are successfully added to the existing list
