Atomic persistence #83
Replies: 2 comments
-
We are kind of doing this with our own IndexedDB integration at the moment. We bind a global row listener on all tables so that any changes in TinyBase can be synced on a row by row basis to persistent storage in a more optimized format but I definitely wish that there was a better experience around this. Ideally there would be a nice way to make it so that writing to the persistence layer is wrapped in a TinyBase transaction so that changes are reverted in memory if for some reason the changes can't be written to persistence |
Beta Was this translation helpful? Give feedback.
-
This is interesting. At the moment, calling a Persister 'save' method explicitly will indeed operate on the whole database. However, once in 'auto-save' mode, since v4, most persisters can access just what changed in the transaction, which means you can do much more surgical updates (like saving to real relational databases like the SQLite persisters do). I feel like this is the flipside of pagination (which is sort of the same more surgical thing for loading) and maybe should tackle it all at the same time. It's a hard and deep and (possibly) breaking set of changes though, so I need to sleep on it a little. |
Beta Was this translation helpful? Give feedback.
-
Has anyone given a thought to atomic persistence, e.g. a way to sync individual keys or rows without sending the whole database over everytime? It doesn't look like it's possible with the current custom persistence API.
Beta Was this translation helpful? Give feedback.
All reactions