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.
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!