This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-01
Channels
- # announcements (2)
- # babashka (10)
- # beginners (133)
- # calva (28)
- # cestmeetup (1)
- # chlorine-clover (31)
- # cider (21)
- # clj-kondo (29)
- # cljs-dev (252)
- # clojure (60)
- # clojure-europe (24)
- # clojure-nl (3)
- # clojure-spec (13)
- # clojure-uk (17)
- # clojurescript (47)
- # conjure (20)
- # datascript (2)
- # datomic (4)
- # figwheel-main (4)
- # fulcro (71)
- # helix (16)
- # jobs (1)
- # meander (56)
- # mount (1)
- # off-topic (15)
- # pathom (25)
- # re-frame (17)
- # reagent (5)
- # remote-jobs (1)
- # shadow-cljs (92)
- # sql (10)
- # tools-deps (71)
- # xtdb (14)
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.
We went with doing a port back to clojure.java.jdbc. We want to leverage the existing code. I’m definitely looking at next.jdbc when I can start from more of a clean slate situation. Although porting isn’t probably that much for a small app like we had. Only about an hour of rewriting. Final note, next.jdbc would’ve been much faster but we can live with clojure.java.jdbc’s performance now.
FWIW, we use both next.jdbc and clojure.java.jdbc in the same code base at work. We build a pooled datasource at startup so that's {:datasource cpds} for java.jdbc and then we just lift :datasource out of that map when calling next.jdbc. It's allowing us to refactor piecemeal to the new library.
But the different defaults for building result sets also mean we either have to use a non-default builder in such code, or else also refactor the code that uses the results. Being able to switch some code to reduce over plan has definition been a big improvement in some places.