Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • S Storage
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 46
    • Issues 46
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 21
    • Merge requests 21
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Open Subsurface Data Universe SoftwareOpen Subsurface Data Universe Software
  • Platform
  • System
  • Storage
  • Issues
  • #41
Closed
Open
Issue created Dec 04, 2020 by Thomas Gehrmann [slb]@gehrmannDeveloper

[System/Storage] Record update collision prevention

The original SDU Storage used

  1. sequential version numbers and
  2. 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

  1. version numbers are system generated (timestamps) and
  2. 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.

Priority

  1. Behavior change: prevent record update collisions/conflicts.
  2. Usability: the int64 numbers are not user friendly; consider usability in the presentation of the version to end-users.

Required actions:

  • Decision whether or not the re-implement the update collision prevention.
    • If yes:
      1. Create a transition plan to support the breaking change;
      2. Usage rules for populating the version number in the create/update requests;
      3. Version number presentation recommendations.
    • If no:
      1. Augment documentation to describe the behavior during update collisions/conflicts and how to detect them.
Assignee
Assign to
Time tracking