...
In order to find the values that have been updated between two data nodes, each leaf node present under the source data node is to be accessed and compared to the leaf node present under the target data node. In doing so all the information about the data nodes relation to other data nodes is lost, because the algorithm accesses each first flattens all the data nodes into a linear structure for easier comparision.
Then the algorithm accesses the source and target data node based on their xpath, then accesses
When it finds source and target data nodes having the same xpath, we fetch the individual leaves nodes of the said data node, which these leaves are then compared and based on if any changes detected the leaves are added to the delta report.
Since the data is accessed at a low level (leaf node) to generate the delta report, it becomes impossible to reconstruct the data node back and represent the updated data in the original JSON/XML structure. Therefore, the best approach is to provide the delta of updated nodes individually irrespective of the fact that they are in a parent-child relationship.
Reconstructing the data node to represent the original data structure would require some kind of data manipulation which is not suitable as it could lead to discrepancies in the delta that is generated.
...
The same is described below in form of the flowchart.
For the following scenarios we take the following source and target data as a common starting point
Expand |
---|
Source Data | Target Data |
---|
Code Block |
---|
[
{
"parent": {
"leaf-1": "leaf-1 data",
"leaf-2": "leaf-2 data",
"child": {
"child-1 data": "child-1 data",
"child-2 data": "child-2 data"
}
}
}
] |
| Code Block |
---|
| [
{
"parent": {
"leaf-1": "leaf-1 data",
"leaf-2": "leaf-2 updated data",
"child": {
"child-1 data": "child-1 updated data",
"child-2 data": "child-2 data"
}
}
}
] |
|
|
Mechanism for comparison
Flattening of Data Nodes before comparing
Gliffy |
---|
baseUrl | https://lf-onap.atlassian.net/wiki |
---|
name | Flattening of JSON |
---|
pageid | 79822969 |
---|
timestamp | 1735206010231 |
---|
|
Flowchart: Mechanism for comparison of Data Nodes to check for updates
Gliffy |
---|
imageAttachmentId | att84869188 |
---|
macroId | 9449afce-5ab1-4b5a-bf40-dc0ba2d2b5d5 |
---|
baseUrl | https://lf-onap.atlassian.net/wiki |
---|
displayName | Flowchart of replace operation in Delta Frature |
---|
name | Update Flowchart |
---|
diagramAttachmentId | att84901971 |
---|
containerId | 79822969 |
---|
version | 13 |
---|
timestamp | 1734600420506 |
---|
|
...
If a parent and its child are updated, then both of them should be reported as 2 separate update operations. This is because when comparing data nodes that have been updated, it is not possible to maintain the parent-child relation of the 2 data nodes as explained above.
Expand |
---|
title | Example Source and Target Data |
---|
|
action "update",xpath/parentsourceData["leaf-2 data",
"child": {
"child-1 data": " |
|
old} ],"targetData":[{data"updateddata" }
]
},
{"leaf-1": "leaf-1 data",
" |
|
actionupdatexpath"/parent/child",sourceData[{ "old], "targetData |
Expand |
---|
|
Code Block |
---|
[
{
"action": "update",
"xpath": "/parent",
"sourceData": [
{
"dataleaf-2": "updatedleaf-2 data"
}
],
}
] |
|
Scenario 2: Parent is updated, child is added or removed
In a scenario where parent node is updated and its child node either added or removed, then in such a scenario each node must be reported separately and grouped based on their respective operation. For example, if a parent is updated and 2 child nodes are either added. Then the delta report should have 2 entries, first an update entry containing details of the updated parent node and the second a create entry containing both the child nodes, grouped together.
Expand |
---|
|
Code Block |
---|
[
{
"action": "update",
"xpath": "/parent" "targetData": [
{
"leaf-2": "leaf-2 updated data"
}
]
},
{
"action": "update",
"xpath": "/parent/child",
"sourceData": [
{
"child-1 data": "child-1 data"
}
],
"sourceDatatargetData": [
{
"child-1 data": "oldchild-1 updated data"
}
],
"targetData": [
{
"data": "updated data"
}
]
},
{
"action": "create",
"xpath": "/parent/child",
"targetData": [
}
] |
|
Scenario 2: Parent is updated, child is added or removed
In a scenario where parent node is updated and its child node either added or removed, then in such a scenario each node must be reported separately and grouped based on their respective operation. For example, if a parent is updated and 2 child nodes are either added. Then the delta report should have 2 entries, first an update entry containing details of the updated parent node and the second a create entry containing both the child nodes, grouped together.
Expand |
---|
title | Example Source and Target Data |
---|
|
Source Data | Target Data |
---|
Code Block |
---|
[
{
"parent": {
|
|
datachild grandchild:[ | Code Block |
---|
[
{
"parent": {
" |
|
datagrandchildleaf-1 data",
"leaf-2": "leaf-2 updated data",
|
|
}] }"child-1 data": "child-1 data",
|
|
]}
] |
Scenario 3: Parent is updated, child 1 is added or removed, child 2 is updated (Siblings scenario) 
If the parent and one of its children are updated while another child is added or removed then in such a case, the parent and updated child will be reported individually as two update operations while the added/removed child would be reported as a separate create/remove operation.
Expand |
---|
|
Code Block | [
"grand-child": [
{
"data": "grandchild data"
}
]
}
}
}
] |
|
|
Expand |
---|
|
Code Block |
---|
[
{
"action": "update",
"xpath": "/parent",
"sourceData": [
{
"dataleaf-2": "oldleaf-2 data"
}
],
"targetData": [
{
"dataleaf-2": "leaf-2 updated data"
}
]
},
{
"action": "updatecreate",
"xpath": "/parent/child-2",
"sourceDatatargetData": [
{
"child-1 data": "oldchild-1 data",
} "grand-child": [
], "targetData": [ {
{ "data": "updatedgrandchild data"
} }
] }, { ]
"action": "update", }
"xpath": "/parent/child-3", ]
"sourceData": [
{
"data": "old data"
}
],
"targetData": [
{
"data": "updated data"
}
]
},
}
] |
|
Scenario 3: Parent is updated, child 1 is added or removed, child 2 is updated (Siblings scenario) 
If the parent and one of its children are updated while another child is added or removed then in such a case, the parent and updated child will be reported individually as two update operations while the added/removed child would be reported as a separate create/remove operation.
Expand |
---|
title | Example Source and Target Data |
---|
|
Expand |
---|
title | Exampleaction"create",xpath/parent/childtargetData [ "leaf-2 data",
"child-2": {
"child-2 data": "child- |
|
1,"grand-child":[ datagrandchildleaf-1 data",
"leaf-2": "leaf-2 updated data",
|
|
}] }
]
] |
---|
Scenario 4: Parent is updated, child remains unchanged, grandchild is updated
This is another scenario which justifies the proposal that every update operation should be reported separately, because if a parent and its grandchild are updated while the child node is unchanged, then maintaining the parent-child-grandchild relation and the original JSON/XML structure in the delta report becomes impossible because the delta report will not contain any information about the child node as it was not updated. Hence making the grouping operation impossible in such a scenario.
,
"child-2": {
"child-2 data": "child-2 data updated"
}
}
}
] |
|
|
Expand |
---|
|
Code Block |
---|
[
{
"action": "update",
"xpath": "/parent",
"sourceData": [
{
"leaf-2": "leaf-2 data"
}
],
"targetData": [
{
"leaf-2": "leaf-2 updated data"
}
]
},
{
"action": "update",
"xpath": "/parent/child-2",
"sourceData": [
{
"child-2 data": "child-2 data"
}
],
"targetData": [
{
"child-2 data": "child-2 data updated"
}
]
},
{
"action": "create",
"xpath": "/parent/child-1",
"targetData": [
{
"child-1": {
"child-1 data": "child-1 data"
}
}
]
}
] |
|
Scenario 4: Parent is updated, child remains unchanged, grandchild is updated
This is another scenario which justifies the proposal that every update operation should be reported separately, because if a parent and its grandchild are updated while the child node is unchanged, then maintaining the parent-child-grandchild relation and the original JSON/XML structure in the delta report becomes impossible because the delta report will not contain any information about the child node as it was not updated. Hence making the grouping operation impossible in such a scenario.
Expand |
---|
title | Example Source and Target Data |
---|
|
Source Data | Target Data |
---|
Code Block |
---|
[
{
"parent": {
"leaf-1": "leaf-1 data",
"leaf-2": "leaf-2 data",
"child": {
"child-1 data": "child-1 data",
"grand-child": [
{
"data": "grandchild data"
}
]
}
}
}
] |
| Code Block |
---|
[
{
"parent": {
"leaf-1": "leaf-1 data",
"leaf-2": "leaf-2 updated data",
"child": {
"child-1 data": "child-1 data",
"grand-child": [
{
"data": "grandchild data updated"
}
]
}
}
}
] |
|
|
Expand |
---|
|
Code Block |
---|
[
{
"action": "update",
"xpath": "/parent",
"sourceData": [
{
"dataleaf-2": "oldleaf-2 data"
}
],
"targetData": [
{
"dataleaf-2": "leaf-2 updated data"
}
]
},
{
"action": "update",
"xpath": "/parent/grandchild",
"sourceData": [
{
"data": "oldgrandchild data"
}
],
"targetData": [
{
"data": "updatedgrandchild data updated"
}
]
}
] |
|