[System/Storage] Record update collision prevention
The original SDU Storage used
- sequential version numbers and
- a validation of the version number during record update. Should an update request refer to a version number less than the current last version, the update request is rejected.
This issue is about recording the difference in behavior between original and current R3 Storage, where
- version numbers are system generated (timestamps) and
- no validation of the version number happens. As a consequence all updates will succeed including apparently conflicting, simultaneous updates.
It is important to understand that the request to restore the previous SDU/OSDU validation is a breaking change, which may require adding the version property to the list of required system properties (=change in Data Definition affecting all records).
Thanks to @doniger to help understand this requirement.
- Behavior change: prevent record update collisions/conflicts.
- Usability: the int64 numbers are not user friendly; consider usability in the presentation of the version to end-users.
- Decision whether or not the re-implement the update collision prevention.
- If yes:
- Create a transition plan to support the breaking change;
- Usage rules for populating the version number in the create/update requests;
- Version number presentation recommendations.
- If no:
- Augment documentation to describe the behavior during update collisions/conflicts and how to detect them.
- If yes: