asami VS odoyle-rules

Consider using Asami which also has time travel on the ClojureScript side: https://github.com/quoll/asami

Asami: A flexible graph store in Clojure\ (0 comments)

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.

My stupid question is: why even bother with B-Trees? I believe asami[0] stores everything in memory using Clojure maps & sets.

[0] https://github.com/quoll/asami

Personally, I make use of Aristotle to build the Danish WordNet based on standard schemas, while I use Asami for a different project at work where I don't have the need for a shared vocabulary.

If you're going down this route I'd second the recommendation for O'Doyle Rules. (Haven't used it since I switched away from SPAs altogether, but when I was investigating stuff in that space, O'Doyle appeared to be taking the "correct approach" from what I could tell.)

That's what this tiny library does https://github.com/oakes/odoyle-rules

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.

I think what we need is to figure out how to combine DataScript with a rules engine. I'm wrote a rules engine and made a writeup that compares the two together: "Using O'Doyle Rules as a poor man's DataScript" https://github.com/oakes/odoyle-rules/blob/master/bench-src/...

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.

Odoyle-rules lets you write rules (forwards chaining) engine that you can run on client and server. There are a couple ways you can twist that idea to achieve a more unified system.

I suspect it'd be too much of a mismatch to be useful, but i haven't thought about it enough. I think a more promising idea is to try implementing a database with o'doyle. I wrote about my first attempt here: Using O'Doyle Rules as a poor man's DataScript Right now it would be too inefficient for large data sets because it has to constantly rebuild its index but i think with some small changes i could improve that and basically turn o'doyle into a tool for creating databases that come with reactivity for free.

No doubt there's a runtime cost in joining the facts together, so naturally a system that lumps facts together into records (like clara) will have to do fewer joins, and should be faster. I figured out that i could at least deduplicate my joins with derived facts as i explained here, which ended up being a really big perf boost. But there's still a tradeoff, and one where almost everyone should favor flexibility, i think.