Overview
In CPS-341 the POST operation to create a new data node was updated to bring support for a multiple data trees under a single anchor (or a single root "/" node). In order to achieve this, the JSON data containing multiple data trees are parsed into a Collection of data nodes.
This collection of data nodes is then converted to a List of Fragment Entities which is stored into the database.
From the above description it is clear that when a GET operation will be performed on an anchor containing multiple data trees to retrieve one or all data trees, it will be returned as a List of Fragment Entities as opposed to a single Fragment Entity being returned earlier.
It is to be noted here that the methods used for GET operation are not limited to Get a Node API and are reused in other API's as well. All the APIS discussed below internally call the getFragmentWithoutDescendantsByXpath()
to retrieve the data trees. This epic covers the impact on all the API's due to the above mentioned changes in CPS core.
A common task across the API's is to maintain backwards compatibility as well.
References
- Jira: Impact analysis on CPS core API's due to changes of CPS-341
- CPS-341 Spike: Support multiple data tree instances under 1 anchor
Open Issues and Decisions
S. No | API | Issue | Decisions |
---|---|---|---|
1 | 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:
| |
2 | CPS Core API's under this link | 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. |
List of impacted API's
Operation | API | Issues | Possible Solution |
---|---|---|---|
GET | Get a Node |
|
|
PUT |
|
|
|
DELETE | Delete a datanode |
| |
PATCH | Update node leaves |
|
|
POST | Add list element to existing list |
|
|
The existing GET operation
//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
//Now returns a List of Fragment entities default List<FragmentEntity> findFirstRootByDataspaceAndAnchor(@NonNull DataspaceEntity dataspaceEntity, @NonNull AnchorEntity anchorEntity) { final List<FragmentEntity> fragmentEntities = new ArrayList<>(findRootsByDataspaceAndAnchor(dataspaceEntity.getId(), anchorEntity.getId())); if (! fragmentEntities.isEmpty()){ return fragmentEntities; } else{ throw new DataNodeNotFoundException(dataspaceEntity.getName(), anchorEntity.getName()); } }