hugsql

Nathan 2025-04-01T15:08:02.808629Z

Hello, I'm having some weird performance issues with hugsql and was wondering if it's something that's already been identified I have a query that's pretty fast ( about 200ms ) and returns a few 1000s rows ( 3-5 mo of data ) If i make the request using jdbc/query it takes about 200 ms as expected but using Hugsql, it takes about 5 seconds which seems like a way to high overhead I'm at a loss on how to understand more about this issue, if anyone could provide any tips it would be greatly appreciated, thanks ! Both query are using the exact same Hikari connection pool

igrishaev 2025-04-01T17:14:17.670389Z

The easiest way to debug will be to log queries and their timings on the database level. Is it a local db or remote?

Nathan 2025-04-02T08:45:55.272779Z

The queries themselves are quite fast, the db doesn't show anything surprising We managed to pinpoint the problem a bit more, we are overriding hugsql-command-fn for most command / result types with another step that mainly transform db keys to kebab-case This seems to prevent caching in some way

igrishaev 2025-04-02T08:49:52.497459Z

It's possible to pass jdbc result-set builder that will process the result, let me find an example

igrishaev 2025-04-02T09:56:14.548639Z

(hugsql/set-adapter!
 (next-adapter/hugsql-adapter-next-jdbc
  {:builder-fn result-set/as-unqualified-lower-maps}))

igrishaev 2025-04-02T09:56:54.685479Z

this code snippet sets the default builder-fn for next.jdbc. You can always pass your custom builder

igrishaev 2025-04-02T09:58:46.912129Z

as follows:

(deftype MyBuilder [^ResultSet rs]

  

  (->row [this]
    ...)

  (column-count [this]
    ...)

  (with-column [this row i]
    ...)

  (with-column-value [this row col v]
    ...)

  (row! [this row]
    ...)

  

  (->rs [this]
    (transient []))

  (with-row [this mrs row]
    (conj! mrs row))

  (rs! [this mrs]
    (persistent! mrs)))

igrishaev 2025-04-02T10:00:02.236579Z

It looks like you're trying to hack something whereas there is a legal way

Nathan 2025-04-02T10:05:27.351559Z

Thanks a lot for all that detailed explanations, I'm going to try to implement it this way Definitely seems like a hack, I'm just trying to understand code that was written a few years ago and seems like we have a bit to fix Currently we are using hugsql-adapter-clojure-java-jdbc and not hugsql-adapter-next-jdbcbut it probably doesn't change all that much

igrishaev 2025-04-02T10:06:57.891209Z

Right, what I meant here, you can pass defaults for the adapter, and the old clojure.java.jdbc library also has an option to receive cebab-keys, or lower_case fields, and so on