Research: Add some kind of mechanism to allow ensuring data consistency with definable rules

[der-gabe]

User Story

We want a way to define certain data consistency rule, for instance:

• This attribute must be set if that other attribute is set
• This attribute must have a certain value depending on the value of another attribute
• This attribute's value must be greater than this other attribute's value

Possible approaches

This could be done in several ways:

• A way to add such rules directly to Entity, Attribute or Value instances
  • It's an open question whether a violation should only throw up a warning, or block the user from submitting/saving the change, at all.
    • Perhaps this should be configurable in the rule itself, as well.
• A generic task framework (similar to the Gitlab CI/CD pipeline) that allows scheduling and running tasks on predefined conditions
  • Tasks would probably need well defined exit/return status, such as simple PASS/SUCCESS & FAIL, or those two plus WARN & ERROR or whatever else.
    • Should allowable status be configurable?
    • How would the tasks themselves, their status and the pipeline as a whole be displayed to users?
  • A data consistency rule would then just be a type of task that e.g. checks and compares attribute values after a change has been made.
  • Again, it's an open question what exactly should happen when the test fails
    • Should such tasks simply exit, returning the appropriate status?
      • Would that alone be enough to alert users to a problem or is something more needed?
    • Should a Change be auto-rejected when it makes a test fail?
    • Should a direct data change¹ be rolled back automatically when it makes a test fail?
    • In case there are more than two possible exit/return values Should that action depend on the exact of the task (iones). If so, how is that dependency
    • Perhaps this should be configurable in the task, somehow.

Procedural stuff

The fact that there are (at least) two possible approaches² and open questions for each one is what makes this a research issue.

Footnotes

Footnotes

1. i.e. one that bypasses Change. ↩

2. and perhaps even more that just haven't occurred to us ↩

[crazyscientist]

Just for reference: #7