mentat VS odoyle-rules

Why did Mozilla abandon the Mentat database?

There is (now unmaintained) project called Mentat [0] from Mozilla.

[0] https://github.com/mozilla/mentat

Mozilla was working on the opposite, a Datalog of SQLite, with Mentat, now abandoned: https://github.com/mozilla/mentat

Strikes me as a basically sound idea and it would be lovely if someone picked up the ball.

mentat was archived by mozilla back in 2017, but there are a bunch of forks. Because github is dumb and has a terrible interface for exploring forks [0], I used the Active GitHub Forks tool [1] that helped to find:

qpdb/mentat [2] seems to be the largest (+131 commits) and most recently modified (May this year) fork of mozilla/mentat.

[0]: https://github.com/mozilla/mentat/network/members - Seriously, how am I supposed to use this? Hundreds of entries, but no counts for stars, contributors, or commits, no details about recent commits. Just click every one?

[1]: https://techgaun.github.io/active-forks/index.html

[2]: https://github.com/qpdb/mentat

There are plenty of open source Datomic Inspired databases. Check out https://github.com/juji-io/datalevin and scroll down all the way down to “Alternatives”. There was even the beginning of a rust one by Mozilla: https://github.com/mozilla/mentat

I think you might be slightly misreading things, from what you quoted it’s about the query language (sql vs Datalog) not the database engine, that would likely be SQLite in any case. Now whether grafting a Datalog query engine onto SQLite is a good idea is a different question (though it’s been done, eg https://github.com/mozilla/mentat), but we should all at least talk about the same thing :)

You might be interested in the now defunct Mentat project from Mozilla. They made an EAV store with syncing on top of sqlite. It ran datalog queries by translating them into sql.

https://github.com/mozilla/mentat

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.