Clojurians Log v2
asami
does anyone use asami in production, as a central db e.g. for re-frame or something similar?
is it even suitable for such purpose?
after a long time I am very disappointed with datascript and I am looking for something instead
When you say, “for re-frame” then do you mean that you have a re-frame app, and you want storage for the data, or are you specifically talking about re-frame structures that will be stored in the database?
Well, I don’t know much about re-frame, so I can’t comment 🙂
btw, thank you for your work @quoll, especially around documentation, nice to read
We had a simpler system based on Rum, where the data was all kept in Asami. But the UI has been pulled out completely and given to a team who does JavaScript. We’re now building an engine that stores everything in Asami, and the engine provides an interface that the JS team can talk to
sounds cool
Some days I just can’t code. Or I want someone else to use a feature, and I know that they’ll never even look at it if it’s not documented. So I write docs 🙂
I think there’s over 100k deployments now, so for the features that the engine team are using it’s holding up well
I’m actually on that engine team, but as Asami got used more and more, I’ve moved to focusing on it
I find it surprising that asami in the clojure world is still somewhere in the shadows of datascript
Well, DataScript has been around a long time, and has been promoted at Clojure/conj
People have heard about it
I first heard about Asami when watching your talk at ClojureD 2019
great talk
Thank you 🙂
The idea of it was that I wanted to give developers (who like to know how things work) a sense of what graphs are, and how a graph database does it
there's a lot of activity around graphs in clojure recently
I’ve noticed!
If I’d known all of this 5 years ago then I wouldn’t have bothered 🙂
it would be a great loss for us
When we started Mulgara, we thought it was a bit of effort, but was not too big an effort. But then the more we did, the more we needed to do. Several years later, the owner of the company said that if he’d known what it would involve, then he never would have committed to it. Because of that, I never wanted to build another complete database from scratch. I knew how much effort that entails. But back in 2016, when I was asked if I could implement my own open source database for Naga (and not rely on Datomic), I figured it would be OK, because it only needed to be in memory, and it only needed to handle storage and join operations. I did that in about a day. Then I decided that it needed a query optimizer (again… easy, because of so few operations), and that only took half of a Saturday. It seemed so simple
Storage at that point looked like this: https://github.com/threatgrid/naga/blob/d36cb2a44d38c27669a52b6b3f421d9db3bc6a96/src/naga/storage/memory/index.clj
The query engine (it did not support a q function… only a :where clause and projection to the required columns) and query planner were here:
https://github.com/threatgrid/naga/blob/d36cb2a44d38c27669a52b6b3f421d9db3bc6a96/src/naga/storage/memory/core.clj
That’s 100% of it
It was nice to have a few words with you Paula
I'll definitely stop by again, but I have to run.
thx!