Aper's data structures attempt to handle conflicts appropriately, but there are cases where that isn't possible. For example:
Alice modifies a list item after Bob has deleted it.
Alice and Bob both modify an atomic at the same time.
Alice makes a move in a game that is now invalid because of a move Bob made.
In these cases, an object representing the conflict should be raised. This would probably be an associated type of StateMachine with a reasonable default (maybe ()).
Design questions:
Should this be a Rust Error? In this case we could use Result<(), Conflict> as a signature for apply
Should apply guarantee that the state has not been modified if a conflict arises, or should it be the responsibility of the state manager to roll back if a conflict comes up?
The latter would simplify the implementation of transactions (#7) because apply could simply raise the first conflict that arose resulting in a rollback of the entire transaction.
paulgb
commented
2 years ago
Aper's data structures attempt to handle conflicts appropriately, but there are cases where that isn't possible. For example:
In these cases, an object representing the conflict should be raised. This would probably be an associated type of
StateMachinewith a reasonable default (maybe()).Design questions:
Error? In this case we could useResult<(), Conflict>as a signature forapplyapplyguarantee that the state has not been modified if a conflict arises, or should it be the responsibility of the state manager to roll back if a conflict comes up?applycould simply raise the first conflict that arose resulting in a rollback of the entire transaction.