This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # beginners (119)
- # calva (2)
- # cider (40)
- # cljsrn (14)
- # clojure (145)
- # clojure-dev (122)
- # clojure-europe (4)
- # clojure-italy (9)
- # clojure-nl (5)
- # clojure-spec (2)
- # clojure-uk (32)
- # clojuredesign-podcast (1)
- # clojurescript (10)
- # cursive (44)
- # data-science (1)
- # datomic (53)
- # defnpodcast (6)
- # emacs (6)
- # fulcro (13)
- # garden (25)
- # graalvm (3)
- # graphql (7)
- # jobs (3)
- # liberator (4)
- # nrepl (1)
- # off-topic (21)
- # quil (27)
- # reagent (4)
- # reitit (2)
- # remote-jobs (1)
- # ring-swagger (3)
- # shadow-cljs (3)
- # spacemacs (24)
- # sql (29)
- # tools-deps (68)
- # xtdb (2)
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]])
["select payload from foos where id in (?)" [1 2 3]]?
JDBC requires a
? for each element.
or something like that.
(jdbc/query db (into [(str "select payload from foos where id in (" (str/join "," (repeat (count data) "?")) ")"] data))
Or use HoneySQL which automates some of that SQL generation for you.
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.
Is there a way to
rollback a transaction w/o raising exception with
how I can do it?
I am using h2 in memory
@kirill.salykin No, in
next.jdbc, the expectation is you throw an exception and
with-transaction will rollback and tidy things up.
You could try calling
(.rollback con) directly but that isn't a test code path right now.
Is there a particular reason you don't want to do this via an exception?
(if you call
(.rollback con) directly,
with-transaction will still try to call
(.commit con) at the end -- not sure how that will behave!)
Exception doesn’t fully fit the flow, but if it expected approach - will use it
I'm curious now 🙂 What's your use case?
Just simple checks with either like monads
So expected to return monad with result
So I think I will throw catch and return then
Is this transaction manipulation thing something you want to be changed in JDBC.next? I may dig and make a pr?
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?
This is an area where
clojure.java.jdbc was very imperative and used side-effects that felt very un-Clojure-y.
Sorry, I am in the bed already , I ll tell more tomorrow
Thanks for help
'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 🙂
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.
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.
(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)