CPS-470 - Getting issue details... STATUS
Overview
The CPS-core notification system only sends data-update events when a root data node is created or the anchor is updated. There is no support for delete change. And, the existing supported operations are also not differentiated in the event. To define the operation type, we need to change the existing event structure and the changes on both the cps-core and cps-temporal sides to support the new event version.
Decision/Issues
| Description | Decision | |
|---|---|---|
| 1 | 'operation' field in the event should be mandatory or optional? | 'optional' because Bell is deploying cps Istanbul in production soon |
| 2 | Multiple root data nodes can have an impact on notification services | Will be evaluated as part of the spike CPS-341 - Getting issue details... STATUS |
Proposal
Operation
| Operation | Scenario |
|---|---|
| CREATE |
|
| UPDATE |
|
| DELETE |
|
Event
Enable Full compatibility
The event V1 schema definition is strict and it is not possible to add any optional fields without breaking the old schema contract. To have the flexibility of adding optional fields in future with full compatibility, we are setting the value of 'additionalProperties' to true in both 'CpsDataUpdatedEvent' and 'Content' definitions.
{
"definitions": {
"CpsDataUpdatedEvent": {
...
"additionalProperties": true
},
"Content": {
...
"additionalProperties": true
},
...
}
}
Add Operation field
The new 'operation' field is added to the event in the content section. The field can be marked as
- optional: It makes the event v2 backwards compatible and the user can upgrade cps-temporal before cps-core. As it is a field that should be mandatory, it should be set as mandatory in the v3 which gives the user a release to upgrade cps-core to v2.
- mandatory: no compatibility with the older version and both cps-core and cps-temporal have to be updated at the same time.
{
"definitions": {
...
"Content": {
"properties": {
"operation": {
"description": "The operation supported by the ",
"type": "string",
"enum": ["CREATE", "UPDATE", "DELETE"]
}
...
}
}
}
}
Optional Data field
The existing 'data' section in the content should not be provided in the delete event and it should be marked as optional. As we are deleting a mandatory field, the change is still backwards compatible.
Event V2 JSON Schema
Delete Event example
{
"schema": "urn:cps:org.onap.cps:data-updated-event-schema:v2",
"id": "77b8f114-4562-4069-8234-6d059ff742ac",
"source": "urn:cps:org.onap.cps",
"type": "org.onap.cps.data-updated-event",
"content": {
"observedTimestamp": "2020-12-01T00:00:00.000+0000",
"dataspaceName": "my-dataspace",
"schemaSetName": "bookstore-schemaset",
"anchorName": "chapters",
"operation": "DELETE"
}
}
CPS-Core
There is no specific operation to delete the root node and it gets deleted when Anchor is deleted. In cps-core, a 'DELETE' notification event should be sent
- when an anchor is deleted or
- delete Data Node is called with root XPath.
We are adding a new operation field in the event and the values for all the existing scenarios must be provided as per the Operation section of the proposal.
In the 'DELETE' notification, the 'data' field should not be provided as defined in the event.
CPS-Temporal
It will store the new 'operation' field in the newly added column in the network_data table. If this field is optional in the event, the default value of UPDATE will be set on the temporal side.
Database Schema
A new field 'operation' of type varchar(20) is added in the network_data table.
Migration
The newly added field 'operation' should have a value of 'UPDATE' for the existing data in the network_data table.