You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think there are good ideas that Evolu could easily implement. For example, imagine two replicas editing the same to-do item. Replica A deletes it while Replica B updates it. After the changes are merged, the to-do item will be both updated and deleted. The question is: What was the user's intention, and how can we preserve it?
In this case, the answer is obvious. If an update was made after the deletion, Evolu should revert that deletion. The user intention is clear: I changed the existing to-do item, so I probably care about it.
Is this speculation right? I think it is, but I'm curious to hear your opinions. Remember, Evolu doesn't do real deletions (yet), so we can restore the state anytime.
The text was updated successfully, but these errors were encountered:
This brand new paper actually describes how Evolu works: https://inria.hal.science/hal-04580135/file/DAIS2024.pdf, except for "maintaining integrity constraints" via "compensation mechanisms".
I think there are good ideas that Evolu could easily implement. For example, imagine two replicas editing the same to-do item. Replica A deletes it while Replica B updates it. After the changes are merged, the to-do item will be both updated and deleted. The question is: What was the user's intention, and how can we preserve it?
In this case, the answer is obvious. If an update was made after the deletion, Evolu should revert that deletion. The user intention is clear: I changed the existing to-do item, so I probably care about it.
Is this speculation right? I think it is, but I'm curious to hear your opinions. Remember, Evolu doesn't do real deletions (yet), so we can restore the state anytime.
The text was updated successfully, but these errors were encountered: