Transitions from one state to another

If each of the CRDT operations (policy and document) allows to compute its validity at any time, it assumes the complete graph traversal, and does not store the result of the evaluation to perform actions resulting from a change of this state. We therefore propose a mechanism to keep track of validity changes during the integration of operations of the \(CRDT_{p}\). In particular, it makes it possible to know for which operations of the \(CRDT_{d}\) it is necessary either to generate the inverse operation (in the event of transition from a valid state to an invalid state), or to apply the effect (in the event of transition from an invalid state to a valid state).

To this end, we store validity results ¹ and transitions (deviations from stored validity) for every operation. The user decides when to effect the transitions, and to this end can query which document transitions exist, as they can be computed from stored policy transitions.

¹ akin to cache, except this store is not cleaned after every policy operation addition, but after every transition has been effected

flowchart TB
    subgraph last
        L(last effected validity)
    end
    subgraph changed
        P(policy transitions) --> I(intervals)
        I --> D(document transitions)
    end
    L -- "isValid(document)" --> D
    L -- "isValid(policies)" --> P

Let us take the example of a cancelled operation after a policy change:

%%{init: { 'theme': 'neutral', 'gitGraph': {'mainBranchName': 'Site1'} } }%%
gitGraph
    commit id: "op1" tag: "+S2{W}"
    branch Site2
    checkout Site2
    commit id: "op2" tag: "Write()"
    checkout Site1
    branch Site3
    checkout Site3
    merge Site2
    commit id: "effect(op2)" tag: "_op2"
    checkout Site1
    commit id: "op3" tag: "-S2{W}"
    checkout Site3
    merge Site1
    commit id: "inverse(op2)" tag: "inv_op2"

inv_op2 supposes knowledge of a transition.