Hi, I'm using next-jdbc with hugsql . I would like to pass an argument to my query to limit batch size of how many rows I am selecting, but I also want to have an adapter that allows me not to have namespace

(hugsql/def-db-fns
  "path-to-query.sql"
  {:adapter (next-adapter/hugsql-adapter-next-jdbc {:builder-fn rs/as-unqualified-maps})})

@brzoskwinka18 can you try rs/as-unqualified-lower-maps instead? https://github.com/nomnom-insights/nomnom.utility-belt.sql/blob/eacec699ba25019f8ebf55cea1e6d2af68a81eff/src/utility_belt/sql/model.clj#L15.

it seems like all I needed was to add the builder-fn as a parameter to the execute function, like this!

(jdbc/execute! db [query batch-size]  {:builder-fn rs/as-unqualified-maps})

I see - I assumed you get the wrong result when using hugsql functions

Yes, jdbc/execute! (and related functions) bypass your hugsql adapter configuration

well I tried it both ways, and it worked with execute!

thanks for your advice anyway 🙂

@brzoskwinka18 :builder-fn is an option for next.jdbc which is why you need it in direct calls to that library's functions. There's an example of how to pass next.jdbc options to the HugSQL adapter in the next.jdbc docs: https://cljdoc.org/d/seancorfield/next.jdbc/1.1.613/doc/getting-started/friendly-sql-functions#hugsql-quick-start -- scroll down a bit to see:

;; add require next.jdbc.result-set :as rs to your ns

(hugsql/def-db-fns "db/example.sql"
                   {:adapter (adapter/hugsql-adapter-next-jdbc
                              {:builder-fn rs/as-maps})})

Always happy to hear ways folks think the docs can be improved...

(I don't know what HugSQL has in terms of docs on how to use next.jdbc?)

BTW, in case folks aren't aware, there's a dedicated #hugsql channel (and I lurk there as well).

HugSQL docs have a dedicated "Adapters" section: https://www.hugsql.org/#adapter

looks like default is to pull in clojure.java.jdbc

Yes, that's their historical default since it's been around much longer. The recommendation these days is to use next.jdbc (since clojure.java.jdbc is no longer being maintained) but I can understand why they wouldn't necessarily want to change their default.

Yeah, we still had to create a small wrapper to smooth the transition from c.j.jdbc to next but it wasn't as painful as it seemed initially