Fork me on GitHub
#sql
<
2022-11-18
>
theequalizer7315:11:57

GM friends, has anyone seen this problem? I’m trying to migrate from korma to next.jdbc, I added the last next.jdbc build to my project.clj and started my REPL using clojure 1.9.0. Then I’m adding a new namespace requiring next.jdbc and when I try to evaluate that ns I’m getting this exception

CompilerException java.io.FileNotFoundException: Could not locate clojure/datafy__init.class or clojure/datafy.clj on classpath., compiling:(next/jdbc/result_set.clj:1:1) 
Any thoughts ?

pavlosmelissinos15:11:49

I think clojure.datafy was introduced after 1.9.0 https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.847/doc/getting-started#installation: > You must be using Clojure 1.10 or later.

pavlosmelissinos15:11:02

For what it's worth we recently (couple of months ago) upgraded from 1.9.0 to 1.11 and it went very smoothly so I highly recommend it!

theequalizer7315:11:31

Yes it is there. I missed that small detail 😅 Thanks. My problems now are bigger than just migrating korma.

pavlosmelissinos15:11:41

Clojure is very stable and backwards compatible; it's unlikely that you'll have any (serious) issues, should you choose to upgrade 🙂

theequalizer7315:11:07

I just did it, all good so far. Thanks

seancorfield17:11:01

@ULP19F687 For what it's worth, Clojure's new versions are typically so stable and so backward compatible that we generally run even the alpha releases in production as soon as they appear.

seancorfield17:11:59

(and all my projects are typically tested on multiple versions of Clojure -- next.jdbc is tested against 1.10, 1.11, and the master snapshots, i.e., what will become 1.12 -- https://github.com/seancorfield/next-jdbc/blob/develop/build.clj#L22-L27 )

theequalizer7318:11:04

btw do you know how to share a connection pool between korma and next.jdbc? or where should I start digging?

seancorfield18:11:09

Never used Korma. It's always been too "ORM-y" for my taste.

theequalizer7318:11:44

Mine too ¯\(ツ)

seancorfield19:11:44

It doesn't look easy to share Korma's DB stuff outside it... it has an atom for the default and then two global dynamic Vars... and I haven't yet figured out whether it always uses a connection pool or how it uses that 🙂

theequalizer7319:11:29

Exactly! There’s nothing to get that pool outside the defdb 😞

seancorfield19:11:42

And it uses the old java.jdbc style hash maps with :subprotocol etc which isn't supported at all in next.jdbc 😞

theequalizer7319:11:38

I added a :jdbcUrl to the spec but if next.jdbc doesn’t support :subprotocol that makes impossible to share the connection pool, and I was getting an error about it.

seancorfield19:11:22

Korma even duplicates a lot of the DB-specific machinery that is in (legacy) java.jdbc code... I think you may just be better off creating your own pool for use with next.jdbc (and I would recommend switching to HikariCP -- it's much better maintained and works better than c3p0).

theequalizer7319:11:55

I was absolutely thinking about switching to HikariCP, which I’ve used before. Thanks