Fork me on GitHub
#sql
<
2021-09-12
>
kirill.salykin21:09:33

Hi Sean with clojure.java.jdbc it seems it was possible to specify connection this way:

{:classname   "org.h2.Driver"
 :subprotocol "h2"
 :subname     db-store}
which doesnt work with next.jdbc (`:dbtype` and :dbname are required) Do you plan to support parity in this? (I was working on MR to switch migratus to next.jdbc, but faced this connection spec here https://github.com/yogthos/migratus/blob/master/test/migratus/test/migration/sql.clj#L13)

seancorfield21:09:21

{:dbtype "h2" :dbname (str (.getName (io/file ".")) "/site.db")} is exactly the same as that.

seancorfield21:09:11

(I've inlined the value of db-store there)

kirill.salykin21:09:28

yes, I know but it may be that some people still use subprotocol/`subname` way with migratus? so would be breaking change for them…

seancorfield21:09:41

Even with c.j.j, the :dbname/`:dbtype` was the preferred way.

kirill.salykin21:09:59

oke, I’ll double check with the maintainer

seancorfield21:09:11

Migratus works with the :dbtype/`:dbname` style db-spec.

seancorfield21:09:24

I don't know why you think there's a "breaking change" there @kirill.salykin?

seancorfield21:09:48

Migratus just uses that whole hash map -- it doesn't care what's in it.

kirill.salykin21:09:02

I am changing migratus to use next.jdbc

kirill.salykin21:09:37

with cjj it is posible to use

{:classname   "org.h2.Driver"
 :subprotocol "h2"
 :subname     db-store}
with next.jdbc - seems like not

seancorfield21:09:10

Correct. I've been trying to get people to stop using that format for years, long before I wrote next.jdbc.

kirill.salykin21:09:02

technically this is breaking change, right? but I’ll double check with maintainer if it is a showstopper thanks

seancorfield21:09:56

Yeah, if folks are still using that old format that I've kept telling them not to use, even with c.j.j, then switching Migratus to next.jdbc will break their core and will force them to switch to the format I've been asking them to use 🙂

🎉 4
seancorfield21:09:29

At this point, I have zero sympathy for anyone still using that old format.

kirill.salykin21:09:57

another question, what is a replacement for cjj db-do-commands in next.jdbc?

kirill.salykin21:09:30

db-do-commands seems to use addBatch

seancorfield21:09:12

Hmm... What does the next.jdbc migration guide say about db-do-commands?

kirill.salykin21:09:56

gooed question. lemme check

kirill.salykin21:09:17

execute! -- has no direct equivalent in clojure.java.jdbc (but it can replace most uses of both query and db-do-commands),

seancorfield21:09:18

I should update it to mention execute-batch! probably.

kirill.salykin21:09:37

there is also this:

If you were using db-do-commands in clojure.java.jdbc to execute DDL, the following is the equivalent in next.jdbc:

(defn do-commands [connectable commands]
  (if (instance? java.sql.Connection connectable)
    (with-open [stmt (next.jdbc.prepare/statement connectable)]
      (run! #(.addBatch stmt %) commands)
      (into [] (.executeBatch stmt)))
    (with-open [conn (next.jdbc/get-connection connectable)]
      (do-commands conn commands))))

kirill.salykin21:09:16

sorry, will read first next time :)

seancorfield21:09:14

Also look at execute-batch! although I think that's more about executing a single statement with multiple groups of parameters.

seancorfield21:09:15

Yeah, execute-batch! doesn't help you there. So the above is "execute a batch of commands in one go".

seancorfield21:09:31

OK, I'm back off to my construction work. Laters!