-
Notifications
You must be signed in to change notification settings - Fork 0
Roll-back strategy and snapshot for each propagation changes. #56
Comments
This is related to tree versioning. But the main idea is that one may make a change to the graph through an operator change to the Architect expressions. We need to talk about the difference between commands and expressions though, as commands is what performs side effects. Anyway, one a command is made, a rollback can be initiated to go back to any point in version from prior commands. |
Something similar to git version management? |
Invalid computation results should ideally not become a snapshot? Maybe during graph computation, instead of mutating existing nodes, create new nodes and link to previous version of the same node. So that we have a trail of change history, and for multi layer/step computations, if a later layer/step fails, earlier computation results can simply be discarded. |
Adding on to the purpose of snapshot, apart from user specifying different snapshots, Adaptation/Emergence could keep track of several snapshots as profiles and switch between them based on different metrics such as request per min, time of day, geographical location of request sources etc. |
I mean similar to MVCC, see persistent data structures. |
Several ways of tree versioning:
|
Snapshot
The Graph Systems needs to record the changes during each Propagation recomputation procedure.
This is mainly for the following purpose:
The text was updated successfully, but these errors were encountered: