# | Issue | Notes | Decision |
---|---|---|---|
1 | Add or Delete leaves handle as UPDATE or ADD/DELETE? | The delta report proposed follows the Json Patch format of representing the differences between 2 JSON data. Apart from this the delta is dependent on individual data nodes of the JSON data, this is because the delta report will contain the action, xpath and the source/target data. And since the xpaths are unique to data nodes and not leaf data, every delta entity in delta report will be between 2 data nodes. Going by the general convention and referring RFC-6902:
| Updated as per notes. |
2 | How to handle multiple changes at different levels? | Since the delta report will contain the xpaths of data nodes changed, so for changes at multiple levels i.e., parent and child data nodes, the approach will be to handle each data node individually and report them in the delta report. | |
3 | More scenarios need to be explored and documented in detail. Such as handling arrays within a json, handling child/grandchild changes. | scenarios such as data nodes at multiple levels, arrays and lists are covered. |
Wherever possible the Delta Feature will throw the same exceptions as defined in CPS core. If any new exception for the delta feature is required, the following will be updated here.
The proposed API will be part of the CPS Data Interface. The following response codes will be returned by the API:
# | Sub Interface | Method | Scenario | HTTP Response codes to be implemented | Notes |
---|---|---|---|---|---|
1 | Data | Proposed API: GET-/v2/dataspaces/{dataspace-name}/anchors/{anchor-name}/delta?anchor2={anchor-name}?xpath={xpath}&descendants={descendants} Proposed method name: getDeltaByDataspaceAndAnchors() | Generate a delta report between 2 anchors in a given dataspace. |
| AnchorNotFoundException should provide the name of missing anchor from the given two anchor names. |
Parameter name | In | Required | Description |
---|---|---|---|
dataspace-name | Path | Yes | Dataspace name |
anchor-name | Path | Yes | First Anchor Name/Reference Anchor |
target-anchor-name | Query | Yes | Second Anchor Name/Comparand Anchor |
xpath | Query | Yes | xpath of the node |
descendants | Query | No | Level of descendants for delta comparison. |
[ { "action": "ADD", "xpath": "/bookstore/categories/[@code=3]", "target-data": { "code": 3, "name": "kidz" } }, { "action": "REMOVE", "xpath": "/bookstore/categories/[@code=1]", "source-data": { "code": 1, "name": "Fiction" } }, { "action": "UPDATE", "xpath": "/bookstore/categories/[@code=2]", "source-data": { "name": "Funny" }, "target-data": { "name": "Comic" } } ] |
The delta report format is based on two RFCs namely RFC 6902 and RFC 9144 . A detailed comparison of the RFCs can be found here.
JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation(JSON) document; it is suitable for use with the HTTP PATCH method.
But in it can also be used to get the differences between two JSON as the JSON patch document represents an array of objects. where each object represents a single operation(op), path and value.
The notation of "operation" is used because the same JSON Patch document can be used to perform HTTP Patch operations. But the operations field can be used as a reference to decide how the "action" field should function in the implementation of Delta report.
The operation "op
" field in a JSON patch document can have following values:
Operation | Description | Delta report equivalent |
---|---|---|
add | Adds the value at the target location; if the value exists in the given location, it’s replaced | if the value is not present in the source json, but was found in the comparand json, then it should be considered an "add" action. |
remove | Removes the value at the target location | if a value was present at the source json, but was not found in the comparand json, then it should be considered as "delete" action. |
replace | Replaces the value at the target location | if a value is present in the source json, but an updated value is present in the comparand json, then it will be considered as "update" action. |
move | Removes the value at a specified location and adds it to the target location | N/A |
copy | Copies the value at a specified location to the target location | N/A |
test | Tests that a value at the target location is equal to a specified value | N/A |
[ { "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } ] |
RFC 9144 YANG data model that defines RPCs intended to be used in conjunction with NETCONF [RFC6241] or RESTCONF [RFC8040]. These RFCs allow a client to request a server to compare two NMDA datastores and report any differences.
|
|
---|
Based on the RFC documentations mentioned above, CPS Delta Report is designed in the format specified in the following code block. This Delta Report takes the features from both RFCs that are best suited for CPS and fulfill its requirements.
The format of Delta report has following key take aways from the above mentioned RFCs:
[ { "action": "ADD", "xpath": "/bookstore/categories/[@code=3]", "target-data": { "code": "3,", "name": "kidz" } }, { "action": "REMOVE", "xpath": "/bookstore/categories/[@code=1]", "source-data": { "code": "1,", "name": "Fiction" } }, { "action": "UPDATE", "xpath": "/bookstore/categories/[@code=2]", "source-data": { "name": "Funny" }, "target-data": { "name": "Comic" } } ] |
The JSON data stored in CPS can be retrieved as Maps, And using this we can find the delta between two anchors retrieved as two separate Maps. The result can be stored in an JSON array with appropriate notations for action, xpath and payload. The following algorithm can be used to find the difference between the two maps and also recursively finds the difference between the child data nodes. The response is in form of a JSON Array which closely represents the JSON Patch format as described above.