My silly mistake, of course - I'd missed out the fact that my starting system included:

:biff/merge-context-fn identity

Though I'm wondering @U7YNGKDHA if assoc-db should be something like this:

(defn assoc-db [{:keys [biff.xtdb/node] :as ctx}]
  (if node
    (assoc ctx :biff/db (xt/db node))
    ctx))

> Because right now use-jetty as this baked-in assumption that you're using the xtdb component as well I wouldn't say that--the whole point of introducing the merge-context fn was to add a layer of indirection so that use-jetty and other components don't have to make that assumption. Given that, I'm not sure if there'd be any benefits to having assoc-db work conditionally (?). Random question--since you're not using xtdb, would it be beneficial if there was an easy way to have biff not pull in xtdb as a transitive dep? Or does it not matter? I guess as long as you don't run into any dependency conflict problems it's probably not a huge issue. But I have for a while thought about various ways to restructure Biff to accommodate that without overcomplicating things.

> Given that, I'm not sure if there'd be any benefits to having assoc-db work conditionally (?). Except maybe as an extra guardrail I suppose

yeah that's fair - I don't feel that strongly about it either way as long as there's an escape hatch tbh - but I remember the first time it threw me and I had to hunt through the source to find it and now I just did it again and so could make life trickier for people less willing/able to do so? but yeah, I wouldn't jump to change it but maybe something to think about 😄

and whilst yes it would be nice not to have unnecessary deps, I think part of the point of biff is that it just works out of the box so definitely wouldn't want to overcomplicate things - I imagine I could use exclusions actually? :thinking_face:

yeah:

com.biffweb/biff {:git/url "", :tag "v0.7.9", :sha "7890f70"
                          :exclusions [com.xtdb/xtdb-core com.xtdb/xtdb-jdbc com.xtdb/xtdb-rocksdb]}

haha totally! I think what I should do at a minimum is write a how-to guide that shows how to replace XT with postgres/sqlite, and then that can discuss the merge-context fn. And yeah, exclusions are part of what I was planning on. The only complication is that Biff will still try to require the xtdb lib, i.e. if you start the app with that in your deps.edn then I'm pretty sure the require will throw an exception, unless I grossly misunderstand something. I was thinking of providing some mock versions of xtdb + possibly other libs, so in addition to adding the exclusions, you can add a dependency to those mock versions.

(the mock versions would have the same API, but all the fns would throw UnsupportedOperationException) You could of course make a mock lib yourself, but it'd probably be best if I provide an official mock lib so that it's always up-to-date

oh yes of course

as long as you don't get into log4j territory 😂

haha yeah, I shouldn't have to go that far hopefully

and fwiw I'm not replacing xtdb with anything, I probably will need it anyway if things develop, the project just hasn't move beyond the "spreadsheet as database" stage yet 😅

ah gotcha! maybe two separate guides would be best, or something