Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The initial proposals described 2 simplified approached:

  • Updating leaf values only (without validation)
  • Updating full tree

Both require almost same effort (comparing to proposed above) with significantly less features delivered. Also these solutions 
are temporary and assume refactoring and proper implementation in future.

Also

According to initial DB schema design (see CPS Internal Relation DB Schema) there are SCHEMA_NODE table and associated
SCHEMA_NODE_ID reference field in FRAGMENT. The assumption these were designed to store the reference to DataSchemaNode object
associated with particular data node for usage as described above.

However the object itself is too complex to by stored as is (serialized). Storing the node identifier as reference to schema node object
is less reliable then just a path from the root (already stored in xpath). Also fetching data by xpath to identify the schema object 
new data belong to (for validation and parsing) seems not optimal and over-complicated.

Data Input / Output Consistency

...

Pointing to parent node in order to parse the child correctly is can be treated as mainly an internal requirement. It means there could be 
dynamic update of both incoming parameters (as internal logic): 

...

As it was initially implemented there is no validation for parent data node existence when persisting data nodes.

Drawio
borderfalse
diagramNameCPS partial data persistence
simpleViewerfalse
width
linksauto
tbstyleinline
lboxfalse
diagramDisplayName
diagramWidth871
revision2

It is unnecessary when the whole data tree is persisted (A) because there is a data for all the levels with no gaps. 
With non-empty initial xpath it makes it possible to
persist to persist data nodes from lower levels of structure hierarchy without upper
level data nodes (B). DrawioborderfalsediagramNameCPS partial data persistencesimpleViewerfalsewidthlinksautotbstyleinlinelboxfalsediagramDisplayNamediagramWidth871revision2 


From one hand it seems extra to persist upper level nodes if these nodes are never requested. From other hand it could lead to data inconsistency
if the parent node being added after child nodes (C). The case  however can be resolved by existing data check before inserting new entries.


Points to discuss/clarify

Addressing a data node through parent xpath in API for insert and update operations (options):

  • using parent xpath for insert only, direct xpath for update 
  • using parent xpath for insert and update operations

The naming for an option (boolean type of) to instruct the

Allowing data node persistence without a parent data nodes. Options:

  • allow, requires implementation of data check for existing parents/children on data node insertion
  • prohibit, requires the implementation of xpath being root node check for data nodes inserted without a parent

Remove SCHEMA_NODE table and references as extra from database or clarify the reason for this data to be stored.