This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-26
Channels
- # announcements (2)
- # asami (2)
- # aws (34)
- # babashka (6)
- # beginners (9)
- # calva (76)
- # chlorine-clover (10)
- # circleci (5)
- # clj-kondo (2)
- # clojure (40)
- # clojure-australia (3)
- # clojure-europe (15)
- # clojurescript (39)
- # conjure (1)
- # core-async (4)
- # cursive (4)
- # datahike (1)
- # datomic (69)
- # figwheel-main (1)
- # graalvm (16)
- # honeysql (9)
- # hyperfiddle (2)
- # jobs-discuss (2)
- # lsp (36)
- # luminus (1)
- # malli (11)
- # off-topic (13)
- # pathom (1)
- # portal (1)
- # portkey (3)
- # reitit (25)
- # reveal (1)
- # rewrite-clj (5)
- # spacemacs (2)
- # sql (4)
- # vrac (90)
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.
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?