Fork me on GitHub
agata_anastazja (she/her)14:12:50

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

  {:adapter (next-adapter/hugsql-adapter-next-jdbc {:builder-fn rs/as-unqualified-maps})})
now my results look a bit like this {events/id "1a252d29-e19f-4e84-9e96-14ce82254988", :events/sequence_number 1} but I would like them to look like this {id "1a252d29-e19f-4e84-9e96-14ce82254988", :sequence_number 1}

agata_anastazja (she/her)15:12:00

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

agata_anastazja (she/her)16:12:40

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

agata_anastazja (she/her)16:12:58

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: -- 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})})

💜 3

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:


looks like default is to pull in


Yes, that's their historical default since it's been around much longer. The recommendation these days is to use next.jdbc (since 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