Clojurians Log v2

I've spent quite a bit of the weekend working on next.jdbc, adding enhanced datafy/`nav` support to it, in an optional (new) namespace next.jdbc.datafy. It adds datafication (and navigation) to several native JDBC object types, making it easier to navigate all sorts of metadata for databases, result sets, and statements.

It's very nice to use with REBL (of course) but it's also interesting to use with raw interop calls since it adds a default datafy/`nav` machinery over plain ResultSet objects. At this point, you can also get datafied result set metadata inside the reducing function (over a plan result). I'm going to continue to expose more of the underlying JDBC landscape inside plan as it can be useful for more complex manipulation of the result set data, but I'll be very interested to hear how folks might start to take advantage of this sort of thing.

(I'll work on documenting all of this over the next few days and get a new release published but feel free to try it out on master and just ask me questions 🙂 in the mean time)

seancorfield/next.jdbc {:mvn/version "1.0.462"} is available on Clojars for folks who want to try out the new datafication stuff.

Hi! We have some existing clojure.java.jdbc code where we extend ISQValue, ISQLParameter and IResultSetReadColumn protocols for making type transformations between server side and database driver data types. Is there a way to reuse that stuff with next.jdbc?

Looks like similar protocols exist: https://cljdoc.org/d/seancorfield/next.jdbc/1.0.462/doc/getting-started/result-set-builders https://cljdoc.org/d/seancorfield/next.jdbc/1.0.462/doc/getting-started/prepared-statements#prepared-statement-parameters

Depending on how you wrote the extensions for clojure.java.jdbc, you may be able to reuse some of that code, but the extension points are somewhat different in next.jdbc. Feel free to ask any questions you may have about how to "translate" that to the new library.