I’m using with-options to pass in default opts. Everything is working fine. I have a feeling that when working with transaction (in tests and special bits of code) that it’s going to be a gotcha remembering to re-apply the options. Seems like the alternative is to wrap the exec* next.jdbc and sql friendly functions and just have them default the options. Anyone else have an approach they like? (to summarize: it’s just a boilerplate and onboarding issue 🤷)

lol sorry, I think I actually see that this is already on Sean’s mind: https://github.com/seancorfield/next-jdbc/issues/172

@tkjone Yeah, I'm seriously regretting ever adding that functionality, TBH. It is a pain to use with transactions, and having a way "add default options" just encourages people to use non-default builders. I wish I'd stood my ground just "forced" people to use the default builder with table-qualified column names.

At work, we use :builder-fn rs/as-unqualified-lower-maps for calls that need to be compatible with clojure.java.jdbc code but, otherwise, we try hard to stick to the default builder for new code.

I agree in general. The thing I am doing is adding the snake case defaults so that I can pass lisp-case columns. I mean, I could just as easily just make sure everything is underscored 🤷

Which actually begs the question, do you just use underscored keys across your apps instead of lispcase? Or do you transform them manually after you read and before you write?