Clojurians Log v2

Updated konserve backends using 0.6.0-alpha1 : • https://github.com/alekcz/konserve-jdbc • https://github.com/alekcz/konserve-redis • https://github.com/alekcz/konserve-couchdb • https://github.com/alekcz/konserve-fire Gonna work on LevelDB this eve.

@alekcz360 Just out of curiosity: did you ever get something working with GraalVM native-image and datahike? (let's say filesystem or jdbc storage, the latter is more likely to work given that postgres also works)

@borkdude I think we should try to get konserve (the storage-layer) with some backend, e.g. filesystem or JDBC, working with GraalVM native-image. It would be a very flexible way to have a zero dependency, minimal overhead Clojuresque core.async compatible database for babashka that can even share data between different processes safely. But I have not had the time to delve into that yet, I have only discussed it with @alekcz360 a few weeks ago. From there we can tackle the hitchhiker-tree and then Datahike as well.

it would be awesome to have this, I agree

@borkdude @whilo yeah I got the older version of konserve to work (the filestore was still WIP at the time), so I imagine datahike shouldn't be an issue. Postgres is the best bet. Derby, sqlite and h2 had some issues I couldn't get around.

I also got HSQLDB to work (also available as babashka pod, as is postgres)

hsqldb might be nice as in, it's an embedded thing as well, comparable to file storage

Yes. The benefit of konserve with the filesystem backend is that it uses nio and therefore you can access a lot of small key-value pairs in parallel without spawning a lot of processes.

It is conceptualized as the minimum interface you would like to have in Clojure to build state management solutions. Not as convenient as SQL, but it makes it easier to build something flexible on top that scales appropriately.

here's the project for hsqldb and postgres btw if you want to see the configs for graalvm: https://github.com/babashka/babashka-sql-pods/ I once tried compiling data_script_. It became a huge binary, but I suspect this is because of some runtime resolve/require things in the code (could be): this usually blows up graalvm binaries

Such as Datahike.

data_script_ is available under a feature flag in babashka if you want to compile yourself or check the source

Cool, thanks 🙂.