Fork me on GitHub
#sql
<
2019-07-02
>
cddr14:07:37

How do you represent a collection parameter to be passed into a sql query? e.g. I thought this might work but it doesn't seem to do what I would have expected (in the mysql variant at least). (jdbc/query ["select payload from foos where id in ?" [1 2 3]])

kirill.salykin14:07:30

maybe ["select payload from foos where id in (?)" [1 2 3]]?

seancorfield15:07:46

JDBC requires a ? for each element.

seancorfield15:07:54

(jdbc/query db (into [(str "select payload from foos where id in (" (str/join "," (repeat (count data) "?")) ")"] data))
or something like that.

đź‘Ť 4
seancorfield15:07:18

Or use HoneySQL which automates some of that SQL generation for you.

mpenet17:07:52

Dunno about mysql but with pg you can just pass a single pg array value to IN/ANY

cddr11:07:04

Yeah I’m used to that kind of thing working in pg so I was a bit surprised that it didn’t work against MySQL. This is “trusted” input so I’m not too concerned about building up the sql string manually although I’m sure I’ll get a slapped wrist by the security team if anyone notices. lol

kirill.salykin22:07:10

Is there a way to rollback a transaction w/o raising exception with jdbc.next and hikari-cp? how I can do it?

kirill.salykin22:07:50

I am using h2 in memory

seancorfield22:07:40

@kirill.salykin No, in next.jdbc, the expectation is you throw an exception and with-transaction will rollback and tidy things up.

seancorfield22:07:09

You could try calling (.rollback con) directly but that isn't a test code path right now.

seancorfield22:07:37

Is there a particular reason you don't want to do this via an exception?

seancorfield22:07:09

(if you call (.rollback con) directly, with-transaction will still try to call (.commit con) at the end -- not sure how that will behave!)

kirill.salykin22:07:10

Exception doesn’t fully fit the flow, but if it expected approach - will use it

seancorfield22:07:59

I'm curious now 🙂 What's your use case?

kirill.salykin22:07:04

Just simple checks with either like monads

kirill.salykin22:07:53

So expected to return monad with result

kirill.salykin22:07:25

So I think I will throw catch and return then

kirill.salykin22:07:29

Is this transaction manipulation thing something you want to be changed in JDBC.next? I may dig and make a pr?

seancorfield22:07:37

I guess I'm finding it hard to imagine what the code would look like in a case where you want to do one or more SQL operations and then (presumably) conditionally rollback or commit... and return... what value?

seancorfield22:07:02

This is an area where clojure.java.jdbc was very imperative and used side-effects that felt very un-Clojure-y.

kirill.salykin22:07:24

Sorry, I am in the bed already , I ll tell more tomorrow

kirill.salykin22:07:32

Thanks for help

seancorfield22:07:09

'k will try to loop back around tomorrow. I'm open to looking at some way to support conditional rollback but I want to avoid the ugly machinery that clojure.java.jdbc had to use -- and it also has to play nice with raw java.sql.Connection objects and be backward compatible 🙂

seancorfield23:07:41

So I tested the manual call to (.rollback con) inside (with-transaction [con ds] ,,,) and it works just fine: it will rollback the work done so far, and then if you do additional work and "exit" the transaction, just that extra work would be committed. Which made sense once I thought about how JDBC TX work 🙂 (duh!). The only problem is you get a reflection warning because with-transaction doesn't ensure the con symbol has a type hint.

seancorfield23:07:48

That is fixed on master now (and the Transactions section of the docs updated to explain the manual rollback case) and will be in 1.0.1 when I release that.

seancorfield23:07:23

(I also found -- and fixed -- a bug in next.jdbc.specs where the spec on the :binding vector was too strict while I was adding tests for the automatic and manual rollback scenarios)