How to prevent or detect diverging states

[wietsedv]

I am considering using LiveStore for my next hobby project but I have a big worry that I have not seen adressed in the documentation or Github issues (I can easily have overlooked it). Namely how to prevent or deal with diverging client databases. I will use React Native and will have to deal with different client (app) versions.

If e.g. a materializer implementatation or event schema changes, client states of different app versions will by definition (always?) diverge. The docs say that I can for instance forward-compatibly add e.g. optional fields. If a new client inserts/updates this field, the old client will not be able to save it to the database (in exactly the same way). This is ok as long as an old client stays old, but when the app updates, the local database of that client will forever have missing data unless it is recomputed.

Currently I believe the only reliable general solution is to delete the state/sqlite db after every app update, but rematerializing can be slow and with frequent app updates that would be bad UX. But perhaps that will not be a huge problem with event snapshots (#465).

I do not understand LiveStore well enough to think of the best solution. My guess is that it would involve automatically invalidating the local state when anything changes in event schemas or the materializer. It would be nice if consistency between event log and sqlite state could be guaranteed in some way and if recomputing could be (mostly) prevented through e.g. snapshots.

I'd be grateful if you let me know if I misunderstand something. Here to learn.

[schickling]

Hi Wietse - thanks for your great question!

Glad you're evaluating LiveStore for your next project. It's totally fair that there might be some unexplored or unproven patterns with LiveStore that need to be explored more over the coming years. So I appreciate your input and awareness of this.

In regards to your concrete question how to prevent divergent states, I think this mostly will depend on the "discipline" you apply when designing your schema and implementing your materializers. I agree that the most reliable way will be to always rematerialize the state from the event history, which is already the default behavior in case your state schema changes. We should probably even extend that default behavior to rematerialize in case the materializer implementation has changed as well.

So I think this is not necessarily a question of the state being correct, which should be guaranteed by rematerializing when the schema or materializers have changed, but rather a question of how this can be done in the most efficient way. Would you agree?

(Note I've converted your GH issue into a discussion as I try to keep GH issues reserved for actionable tasks.)

[wietsedv]

Thanks for your answer! It's indeed mostly about efficiency compared to rematerializing whenever in doubt. I'll let you know if I get any useful insights later.