Clojurians Log v2

I'm running the README example:

(defn -main [& _args]
  (let [db-uri "asami:<mem://dbname>"
        _ (d/create-database db-uri)
        conn (d/connect db-uri)
        first-movies [{:movie/title "Explorers"
                       :movie/genre "adventure/comedy/family"
                       :movie/release-year 1985}
                      {:movie/title "Demolition Man"
                       :movie/genre "action/sci-fi/thriller"
                       :movie/release-year 1993}
                      {:movie/title "Johnny Mnemonic"
                       :movie/genre "cyber-punk/action"
                       :movie/release-year 1995}
                      {:movie/title "Toy Story"
                       :movie/genre "animation/adventure"
                       :movie/release-year 1995}]
        _ (d/transact conn {:tx-data first-movies})
        db (d/db conn)]
    (prn (d/q '[:find ?movie-title
                :where [?m :movie/title ?movie-title]] db)))
  ;; =&gt; ()
  (shutdown-agents))

This is with 1.2.6

Ah, deref-ing the transaction did the trick:

_ @(d/transact conn {:tx-data first-movies})

I tried out asami with GraalVM:

$ ./asami
(["Explorers"] ["Demolition Man"] ["Johnny Mnemonic"] ["Toy Story"])

works like a charm.

Hopefully it will keep working with durable storage. It could be pretty cool to build small CLI apps that have persistent datalog storage

I should document that. The transaction occurs in a future on the JVM, and it hasn’t had time to update the connection with the new database yet. This isn’t the case in ClojureScript, since it doesn’t use an extra thread there.

Makes sense.

I haven’t been checking Graal while doing the durable stuff, but I hope it will. The JVM version is based on memory mapped files. I’d hope that it’s the same in Graal, but I also know that this is a rarely used feature in most Java apps

We'll see :)

sqlite for datalog, would be cool

It’ll be cooler when we have it seamlessly working in ClojureScript as well. That’s being developed in parallel, but with some delay as I get it going on the JVM first

I have tried datahike with GraalVM some years ago, but couldn't get that working

If it ends up being a problem, then I’d be willing to work through it

I remember your talk from ClojureD in 2019. Nice to see that asami came a long way since then

It’s weird… people keep asking me for features :rolling_on_the_floor_laughing:

Development has slowed right down while I build the durable storage. That’s going well though. I now have a data pool (maps data to IDs, and IDs back to data). I’m actually considering copying it out into a separate library to provide a fast key-value store

That would help me gather feedback on how well it’s working. So far I haven’t put more than a few MB into it

I've been considering loading in a few gb of data, and moving our user system over to asami.

@borkdude I have been equally excited about the prospect of using SQLite for some time now in this context. 🙂

@dominicm I can only hope it will work well. What I can say is that benchmarks with Mulgara on a 2008 notebook computer did very well up to about 20GB. After that, it started to slow as it had more and more cache misses, but it was still scaling linearly to over 100GB. This design copies a lot of Mulgara, with a few differences: • Mulgara was 100% Java. Asami is 100% Clojure. There will be some overhead, but I don’t expect it to be significant in relation to I/O. • Mulgara used additional structures to track blocks that are no longer in use so that they can be recycled. This required additional I/O. • Mulgara used 6 indexes. Asami will use 4. • Mulgara’s data pool was less space efficient. Overall, Asami will use less space, and have fewer I/O operations. It ought to be significantly faster than Mulgara, and I know that Mulgara is still considered fast, despite the codebase being nearly 20 years old!

So, I don’t know, but I am confident 🙂