Fork me on GitHub
#asami
<
2021-09-26
>
zeitstein08:09:29

Thanks for the detailed response. (And absolutely no apologies necessary!) > You can do this, but it sounds like more work that you need. Is there a reason to avoid having it on disk? The reason is a comment you made here: "in-memory databases are orders of magnitude faster". Since I would be using the database for UI state management and rendering, I thought that in-memory would be preferable. But, maybe on-disk would be feasible as well? > If you move the data between databases like this then you’ll lose the history, and you’re wearing the cost of indexing it as you write to disk. I will have to think about losing histories. Thanks for making note of it.

zeitstein15:09:27

Thinking more about histories, it would be desirable to store the full history on disk, while it would be fine for the in-memory one to start fresh each time and use it just for undo/redo. So, instead of dumping everything to disk from memory, it might make more sense to do some periodic batch transactions. This should be doable, right?