sql

All things SQL and JDBC...
2020-06-02T03:55:42.120800Z

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.

seancorfield 2020-06-02T04:00:25.121Z

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.

seancorfield 2020-06-02T04:01:57.121200Z

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.

nate 2020-06-02T23:22:40.125600Z

I just wanted to stop by and say that I've been using next.jdbc recently (after spending most of my clj life using mongo), and I've found it to be superbly documented and straightforward to use. Today I had to insert into a table with odd column names that threw off the default quoting rules, and then I found https://github.com/seancorfield/next-jdbc/blob/master/doc/friendly-sql-functions.md#table--column-entity-names which talks about the next.jdbc.quoted namespace and my problems quickly went away. Thank you @seancorfield!

4
2