I'm not sure what the concern might be here as my understanding is that they are orthogonal, i.e. open-q works the same whether inside a (with-open [db (c/open-db node)] ...) or not (asides from the transparent performance benefits of pooling the underlying caches & KV index iterator resources) That said, I might be missing something, and your fancy clojure.lang.ref.Cleaner machinery could well break those assumptions very easily. I'll double-check and confirm with you again here tomorrow 🙂

it's just a vague memory.. I think you mentioned it actually

Circling back to this after some discussion - I can confirm there should be no issue. That said, I will write a test for running multiple concurrent open-q's inside an open-db, since we don't actually have a test for that right now.

Just caught a bug with open-q where if I try to return a lazy sequence (e.g. a filter instead of a filterv) it actually crashed the whole JVM

are you using with-open such that it's trying to realize the lazy seq after the open-q snapshot has been closed? laziness and RAII-semantics don't really mix, I've found

Yeah exactly. It's just crazy that it doesn't simply fail, but actually crashes the whole JVM

I fixed my code to realize within the with-open but I thought that was a pretty nasty edge case to point out

> I fixed my code to realize within the with-open I'm relieved to hear that worked 🙂 I agree it's a sharp edge though. Sadly there's not much we can do functionally to change the situation (due to how the native interop works), but do you think a strong warning in the docstring would help?

Yeah. Currently the docstring says attempting to iterate when closed is undefined. Perhaps it varies by operating system?

I think crux could manage the lifetimes of resources opened through its api internally (e.g. expose a crux/close that safely schedules a .close, to be run only when all references to the db are gone) rather than push it on the user, though dubious whether it's worth the complexity/effort

or discourage the use of with-open in favor of a with-streaming-results type macro that wraps the form and forces data realization

I dunno if that's too hand-holdy though

both interesting ideas, thanks, I'll add notes to the board to discuss in due course. We'll at least improve the docstring for now!