@here https://github.com/threatgrid/asami/wiki/Asami-2

The JVM version now accepts URLs of the form: asami:

These are saved in the current working directory in a directory with the same name as the database name

It’s alpha, so it has a way to go. I would love some feedback please

Congratulations, it's very impressive and I am looking forward to trying it out on Monday first thing. I quite enjoyed reading the white paper, these kind of things are not always very well documented and the fact you wrote this early speaks for the attention to details while designing Storage.

About tempids: I was wondering if it would not be better to have them returned as strings (or something else than keywords, since they will end up filling the keyword "cache", the weakmap for interning on the jvm and whatever is used in cljs).

I have been considering this as well. The storage doesn’t actually care, but of course as you access them you’ll start interning them. I was wondering about creating a type (as Datomic seems to have done) or else using URIs (which are flexible and follow RDF). Strings aren’t really a great idea as they become difficult to distinguish between scalars and entity references

Good points.

OK… I have an approach to work on this. I’m adopting a new type. My biggest issue was encoding, but I’ve handled that part now. I’ll do an update when it’s all done 🙂

The memory usage had occurred to me a few years ago, but at that point the entire thing was in memory, so I decided not to worry. I had thought of it again more recently, but decided that since they’re only seen when you pull them in from disk, then it was probably OK for the moment. But it was never going to work long term. However, when I thought about it today a bigger issue came up. These keywords are created with gensym. That means that if the database is opened multiple times, then generating internal nodes has the potential to reuse identifiers. Oops 😳

I’m adding the id counter to transactions, and creating a new datatype that encodes efficiently.