Clojurians Log v2

moving to #asami

Can I please check… did you include the line: (require '[asami.core :as asami]) ?

Oh, I see what I’ve done. I forgot to include something else

yes

side effects eh? 🙂

No, when I ran the example code I’d already required a different namespace, and I forgot to include it in the example

Try the example script now

that 👍 works thanks

(I meant the side effects to auto register asami on namespace load)

Incidentally is it possible to essentially do what is in the README, but without using the connection management and mutable database stuff. i.e. to manage asami and naga as pure values myself, or at least put them in atoms I control?

I just added a comment too. That extra line loads the Asami connector. • It registers the factory function • It extends Asami connections to the ConnectionStore protocol • It implements the Naga Storage protocol

I’ve kinda pushed the value management into the Connection. The Connection actually refers to all the old values of the database, as well as the latest. So if you called (asami/db connection) before running Naga on it then you’ll get the latest value of the database. Afterward, if you use asami/as-of you can still get that same value. It’s actually transparent inside the Connection object. There’s a vector of every database value

This seemed to be the most sensible way to manipulate the database. After all, Datomic follows the same paradigm, where connections are executed against, and new values of the database are created that can be retrieved from the connection

I was thinking more for transient usecases, i.e. where you just want to compute a value… e.g. load some triples into asami, expand the graph with naga rules, and then spit the data or a query result out… without having to engage in resource management etc

e.g. possibly also in the context of a http request… i.e. querying data out of a sparql triple store with constructs, but using asami perhaps with naga in place of a Jena/RDF4j model to build a response.

In that case, I would just use a graph URI with asami:mem:// for the scheme. It’s basically doing exactly what you just said. (admittedly, the asami:local:// scheme is still a work in progress. So you HAVE to use asami:mem:// for now anyway). There’s no “resource management”, except that the connection holds an atom for the vector of DBs, and when you do a transaction like Naga does, then it just calls update on the maps that make up the latest DB, and does a conj to the vector in the connections atom.

My colleagues are doing this all the time. Create a memory graph, throw data into it, and use queries to pull out exactly what they want. Then they throw it all away. 😱

I was a bit shocked to see them do it, but it’s fast, and they find it useful to do!