AmpersandTarski / Ampersand

Build database applications faster than anyone else, and keep your data pollution free as a bonus.
http://ampersandtarski.github.io/
GNU General Public License v3.0
40 stars 8 forks source link

Implement Cork rules #1402

Open stefjoosten opened 1 year ago

stefjoosten commented 1 year ago

As a user of a generated Ampersand prototype, I want to switch invariant rules to process rules and vice versa, provided I have sufficient management privileges within the prototype framework.

What are invariant rules and process rules?

At run time, an invariant gives red messages when violated and blocks further commits in the database, ensuring that this rule stays satisfied at all times. A process rule produces yellow messages when violated and doesn't block anything. It is called a process rule because each violation signals that someone has to do work. By merely signaling the violation, it makes users aware they should make the violation go away. These violation signals are available for all users who have the role specified in the MAINTAIN statements of this rule.

The cork mechanism

Putting a cork in a process rule is a metaphor. It means that new violations of this rule will be blocked, to ensure that the rule will eventually be violation free. After you "cork a rule", every existing violation stays put until it is resolved. However, new violations will be blocked, to ensure that the number of violations can only decrease. After the last violation is resolved, the rule behaves like an invariant. A user does this for example in a migration process, where a new invariant is being implemented in a live situation. The invariant cannot be implemented straight away, because it may cause violations that block the database. The cork mechanism allows us to install the new rule as a process rule and let it become an invariant as soon as its last violation has been resolved.

Task

Implement the cork rule mechanism, so that a user with sufficient privileges can switch any rule from invariant to process rule and vice-versa at run time.

Michiel-s commented 1 year ago

Nice idea. This can be implemented in the prototype framework quite easily. We already have a relation in the database for every conj to store violations. This is the so-called conj cache. Currently, it serves a performance purpose by providing violations to the user faster.

We can extend the current functionality of the conj cache to facilitate the corking mechanism by blocking new rule violations and letting existing violations be. Existing violations are the violations in the conj cache at the moment of corking the rule.