Reactive updates is the big one, in my opinion. DataScript is a triumph and arguably is the reason why so many note-taking tools (Roam, Athens, Logseq, etc) are written in Clojure. But there are so many cases where it would be nice to react when some set of entities is changed.<p>I think what we need is to figure out how to combine DataScript with a rules engine. I wrote a rules engine and made a writeup that compares the two together: "Using O'Doyle Rules as a poor man's DataScript" <a href="https://github.com/oakes/odoyle-rules/blob/master/bench-src/todos/README.md" rel="nofollow">https://github.com/oakes/odoyle-rules/blob/master/bench-src/...</a><p>Subscribing to individual entities is nice but with a rules engine you have so much more fine-grained control over your reactions. And with the RETE algorithm this can be done efficiently. Most libraries in this space just ignore it and make their own ad-hoc solution -- an informally-specified, bug-ridden, slow implementation of half of a rules engine.
Notion alumnus Chet Corcos (<a href="https://twitter.com/ccorcos" rel="nofollow">https://twitter.com/ccorcos</a>) is working on a local-first database that matches a lot of these ideas:<p><a href="https://github.com/ccorcos/tuple-database" rel="nofollow">https://github.com/ccorcos/tuple-database</a>
The big question is: if you don't need queries (which I agree you don't), then why bother with DataScript at all? Why not just store your data in native Clojure/ClojureScript data structures, using the right structure for each thing and use a small number of data access functions, possibly maintaining an index or two?<p>This is what I did: migrated an app (arguably a fairly complex one) from DataScript to native Clojure data structures. Not because I didn't like DataScript: I actually liked the idea a lot, but because I couldn't justify the cost in performance and complexity (in my case, DataScript not handling nil values was a problem as well).
The "Optimized B-Trees" section I _think_ is suggesting to get rid of datoms, which I 100% agree with. I do not think they add anything at all; IME you can have a collection of all attributes indexed by entity ID and then have additional indexes on top of that collection.<p>My stupid question is: why even bother with B-Trees? I believe asami[0] stores everything in memory using Clojure maps & sets.<p>[0] <a href="https://github.com/quoll/asami" rel="nofollow">https://github.com/quoll/asami</a>
I know the founders of InstantDB [1] are using some of these ideas for inspiration :)<p>[1]: <a href="https://www.instantdb.com/" rel="nofollow">https://www.instantdb.com/</a>
Very good pointers, match my thinking on the topics I had considered.<p>One thing though is that I'm not a fan of uuids, I think content addressing is sufficient if you build everything around that. Actually I feel all IDs can be content address and type/name/context. Ofc I'm approaching this slightly differently, I don't care about web browsers but I care about p2p and replication..
How come there is no SQLite of Datalog? You can find plenty of implementations of embedded datalog database in a specific language, where the query API is tied to the language. I want to write text datalog queries and access my database from multiple languages. Why doesn’t this exist?
Sounds like the feature set of RxDB [1].<p>[1] <a href="https://github.com/pubkey/rxdb" rel="nofollow">https://github.com/pubkey/rxdb</a>