Ensure idempotent and commutative updates

[kitten]

Now, this is a tough one but we may want to think about this for offline support that is reliable. A lot of this is well summarised in this talk: https://youtu.be/DEcwa68f-jY

We already have a concept of commutative updates. When we apply optimistic updates, they’re only applied to separate layers in a consistent order. This order can never break down. Once an optimistic layer is created and updated, this update is commutative and idempotent.

That means, the order of these changes doesn’t matter after an optimistic update is applied and it can be applied repeatedly without changes.

This doesn’t quite apply to all of our other updates. Our other updates that are non-optimistic are made to our source of truth, the main store.

When they’re applied again in a different order and have overlapping data, you may get a different result.

This will eventually be an issue on offline connections, when updates and queries are delayed and change order. It’s also an issue when we reapply queries and updates as we come back online.

Optimally we’d like to apply queries in a set order, their execution order, or out of order with some ordering guarantee. The same goes for updates.

Two ordering cases that we could address are:

• Keep a clock counter on the initial operations that will lead to network requests (non-optimistic, non-local)
• When results come back, we should never be able to override any field that from data that has a lower clock than the last writer to that field

These two guarantees would be enough to ensure consistency as far as I can tell... this is called a “Last Write Wins” map

I’ll try to keep this thread up-to-date with some ideas as we go ✌️