Early on, there was a lot of back and forth between myself and @U055NJ5CC about how to get the most performance out of it -- he's a real "performance nut" so that was very valuable.

You would need to use a custom builder based on a record, to improve on basic hash map builder performance -- there's an example in the test suite.

In general, I'm always fairly resistant to adding new options/features for some edge case if it would introduce a performance overhead for "all users". It's fine if something can be done in a way that only users of a particular feature feel the performance pain of that feature.

All that said, I haven't spent much time recently looking at performance optimizations so if you want to spend time on that, feel free. Just remember: no breaking changes 😉

Cool, thanks for the answer.

• jdbc-next is a great and feature-rich library, we use it in all the projects • I believe there would be some small performance wins still available, but if one needs brutal performance, much thinner wrapper on top of java should be created • some perf numbers from 4y back in the 🐷 repo comparing java & clojure options: https://github.com/metosin/porsas • in the (silly) Techempower Bencmarks, my old clojure-entry seems to be still https://www.techempower.com/benchmarks/#section=data-r21&test=db on single query. It’s running on really old version of libs, I think it would be reasonable to get into top 5 with small rewrite. no ambitions for doing that

Someone reported this as a bug on next.jdbc and I told them to report it as a bug on nippy instead 🙂

Or just strip metadata from data before serializing it.

(defn post-read*
  [entity {:keys [prop->column-type-hint transform-keys entity-type post-read-please-don't-use]
           :or {post-read-please-don't-use identity}
           :as repo-config}]
  (-> (with-meta entity {}) ;; next.jdbc returns results with metadata which makes
                            ;; nippy fritz because it doesn't know how to seralize it
      (rename-keys transform-keys)
      (postgres/coerce postgres/read-coerce prop->column-type-hint)
      post-read-please-don't-use
      (core/add-transient :entity-type entity-type)))

post-read-please-don't-use -- what an awesome symbol name!

Thank you 🙂 It’s an escape hatch that should be used sparingly.

post-read-please-don't-use-unless-you-really-have-to 🙂