CPS-1152: Spike Conform JSON and dmi-registry Casing Conventions
CPS-1152: Spike Conform JSON and dmi-registry casing conventionsClosed
Issue:
NCMP has an inconsistency between the JSON supplied/received and what exists in the database. This is producing issues such as those related to CM Handle querying.
Create a CM Handle | Get a CM Handle | Query CM Handle | |
---|---|---|---|
URI | |||
JSON BODY | { | N/A | { |
JSON RESPONSE | N/A | { | [ |
Inconsistencies |
|
|
|
Description | Backwards Compatible | Convention Impacts | Overall CPS Convention impact | Consistency between yang model and JSON | Cost | Comments | |
---|---|---|---|---|---|---|---|
1 | Change OpenApi to kebab-casing | No - This would involve changing what is in red above. So changes to cmhandle registration and JSON responses. |
| Would expect all endpoints to use kebab-casing: dataspace-name, schema-set. | Solved | Some endpoints effected Version management needed | Not backwards compatible is a big issue |
2 | Change dmi-registry to camelCasing | No - Would involve internal changes. Only changes to CM Handle API. | IEEE Guidelines state yang identifiers should be in kebab casing https://1.ieee802.org/yang-guidelines/ | Would expect all endpoints to use camel-casing: dataspaceName, schemaSet. | Solved | Liquibase updates | Not even considering, too many impacts to codebase and breaks yang convention. |
3 | Do nothing / Document | Nothing changes | Conforms to conventions | Would expect all endpoints to use kebab-casing: dataspace-name, schema-set. | Inconsistencies not addressed | Describe in RTD | Team recommends |
Foreseen Impacts
Change OpenApi to kebab-casing
We would change components.yaml to kebab-casing
components.yaml example | |
---|---|
components.yaml currentCmHandleCompositeState:
type: object
properties:
cmHandleState:
type: string
example: ADVISED
lockReason:
$ref: '#/components/schemas/lock-reason'
lastUpdateTime:
type: string
example: 2022-12-31T20:30:40.000+0000
dataSyncEnabled:
type: boolean
example: false
dataSyncState:
$ref: '#/components/schemas/dataStores' | components.yaml futureCmHandleCompositeState:
type: object
properties:
cm-handle-state:
type: string
example: ADVISED
lock-reason:
$ref: '#/components/schemas/lock-reason'
last-update-time:
type: string
example: 2022-12-31T20:30:40.000+0000
data-sync-enabled:
type: boolean
example: false
data-sync-state:
$ref: '#/components/schemas/dataStores' |
This would change generated Java class:
CmHandleCompositeState.java example | |
---|---|
CmHandleCompositeState.java currentpublic class CmHandleCompositeState {
@JsonProperty("cmHandleState")
private String cmHandleState = null;
@JsonProperty("lockReason")
private LockReason lockReason = null;
@JsonProperty("lastUpdateTime")
private String lastUpdateTime = null;
@JsonProperty("dataSyncEnabled")
private Boolean dataSyncEnabled = null;
@JsonProperty("dataSyncState")
private DataStores dataSyncState = null;
public CmHandleCompositeState cmHandleState(String cmHandleState) {
this.cmHandleState = cmHandleState;
return this;
}
... | CmHandleCompositeState.java future |
And change JSON payload:
JSON Payload | |
---|---|
Change dmi-registry to camelCasing
Change the dmi-registry
dmi-registry | |
---|---|
Would involve new Liquibase changeset and updating dmi-registry everywhere.
Java code changes related to CmHandleQueries
Open Questions
Do we want to match the dmi-registry in its entirety? See below inconsistencies for CM Handle registration body: | |
---|---|
CM Handle Registration Body | CM Handle Registration Body Conforming to dmi-registry |
"cmHandle": "CmHandle1" | "id":"CmHandle1" |
"publicCmHandleProperties": [ ] | "public-properties": [ ] |
"cmHandleProperties": { | "additional-properties": { |