note that I got it to work well by simply adding the datalevin to the deps.edn file in nextjournal - the only thing left to really deploy it is to figure out where the database files should reside and how they are persisted...

You may try adding :nosubdir to :flags when run open-kv. Please let me know if it works.

thanks for the suggestion! I see two data files being created for datavin-db: lock.mdb and data.mdb. Are those the only two?

the reason I ask is that nextjournal has a somewhat (convoluted?) way to refer to files in their version filesystem: you have to literally ask nextjournal GUI for the name and then manually add a reference to those files in your code (https://nextjournal.com/help/uploads-and-results?version=published).

Also... when i close the db-connection, does the lockfile get discarded/deleted (this could possibly be an issue when a new file gets created and an old lockfile exists on the versioned filesystem? Also to backup the db, should I only worry about the data.mdb file, forget the lock.mdb, or are there potentially others? Sigh... sorry for all those Qs - should have been easy...

So far I had been using "get-conn", which feels a little different from your suggested "open-kv" - do both return a same kind of connection to work with? (I can see that only open-kv allows you to pass in a :nosubdir in the option's :flag vector...)

If you are using the Datalog db, then there’s no option to avoid the data directory. open-kv is for working with the key-value store.

Yes, the two files are the only files and they have fixed names. They will not be deleted.

when you do backup, you only need to specify the directary, not the file names inside.

Backup should be done with Datalevin copy, not file system utilities.

would datalevin work with symbolic links to the data&lock.mbd files? one option would be to copy the two files after creation into the versioned filesystem directory /results, get their file references, and create symbolic links to those files in the ephemeral filesystem like "/db/", and use that /db in the get-conn call... (also waiting for some more advise from the nextjournal folks...)