This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # babashka (135)
- # beginners (82)
- # calva (55)
- # chlorine-clover (23)
- # cider (13)
- # clara (1)
- # clj-kondo (39)
- # cljs-dev (1)
- # cljsrn (2)
- # clojure (96)
- # clojure-france (3)
- # clojure-uk (24)
- # clojuredesign-podcast (1)
- # clojurescript (56)
- # conjure (73)
- # core-typed (1)
- # cursive (1)
- # datomic (10)
- # fulcro (57)
- # joker (4)
- # juxt (1)
- # malli (20)
- # meander (2)
- # off-topic (54)
- # re-frame (4)
- # reagent (3)
- # shadow-cljs (11)
- # spacemacs (6)
- # sql (26)
- # tools-deps (7)
@nick.romer if the executable isn’t an option, you could also try the LSP server which uses a regular JVM
@nick.romer Can you remind me where I asked this? if this was about cross-compilation, it doesn't necessarily mean ARM is not supported
GraalVM offers downloads for mac arm64, linux arm64, but also aarch64 which I think is arm?
Is this a false positive? It looks like defining a custom
def macro in a namespace (like spec does) doesn't overshadow the special form, but clj-kondo considers it to be the case
(ns foo) (defmacro def [x y z] ,,,) (def x 42) ;; -> foo/def is called with 2 args but expects 3
@qythium Correct, that is a false positive. E.g. spec also defines def but a special form is always prioritized over var names: https://github.com/clojure/spec.alpha/blob/5a4834eeb2967b2eca382efe0afcb3f590bdb3c2/src/main/clojure/clojure/spec/alpha.clj#L349
Thanks! I wonder if it's idiomatic to actually do this or deserving of a warning, given the precedent in clojure.spec. After all it's not shadowing anything and can only be referred to in fully qualified form
@qythium yeah. I think a warning would be appropriate (which you can then fine-tune using a config).
Is there any way to get the clj-kondo to exit with status 1 iff errors are present? Ie ignore warnings. I’m currently relying on parsing the output.
Hm did that change recently? I remember looking at exit codes when I started. Still needs a small wrapper but better than parsing output.
clj-kondo v2020.04.05 - warn about conflicting alias - optional warn on usage of get-in, assoc-in etc. with single keys and other stuff! https://github.com/borkdude/clj-kondo/releases/tag/v2020.04.05
@borkdude Awesome new release -- thank you! With the
with-(db-?)-transaction support, it found a couple of places where I accidentally did this
instead of this
(jdbc/with-db-transaction [t-con db-spec] (jdbc/execute! db-spec [,,,]))
so that's a real bug in the code it found!
(jdbc/with-db-transaction [t-con db-spec] (jdbc/execute! t-con [,,,]))
@U0HJNJWJH Did you ask something to the JDBC maintainers or clj-kondo? I don't follow
In my project I wrote a macros around your macros for shadowing.
(defmacro with-transaction "Helper for `jdbc/with-transaction` allowing specify connection symbol only once and shading non-transactable name." [spec & body] (let [spec (if (vector? spec) (into [(spec 0)] spec) [spec spec])] `(jdbc/with-transaction ~spec [email protected])))
I don't recall seeing that come up in #sql but I do remember you asking about
(with-transaction con ,,,) as a shortcut for
(with-transaction [con con] ,,,) and I said it wasn't a good idea to have two different syntaxes for a macro -- and why I think your
with-transaction is a bad idea too.
Stuart Sierra talks about why that's an antipattern: https://stuartsierra.com/2015/06/10/clojure-donts-heisenparameter
@U04V70XH6 My question was not about collection/not collection.
My question was about making
db-spec not available inside transaction because this name is replaced (shadowed) with
t-con inside the block.
In case like this even linter will not help (because
t-con is already used):
(jdbc/with-db-transaction [t-con db-spec] (jdbc/execute! t-con [,,,]) (jdbc/execute! db-spec [,,,]))
Found my original question in archive Did you consider next.jdbc API for with-transaction where sym shadows name of transactable ?
; Current API (with-open [conn (jdbc/get-connection my-datasource)] (jdbc/with-transaction [tx conn] (jdbc/execute! tx ...))) ; what is allowed to do with `conn` here? ; Alternative - the lexical scope of `conn` is changed (with-open [conn (jdbc/get-connection my-datasource)] (jdbc/with-transaction [conn] (jdbc/execute! conn ...))) ; outer `conn` not accessible here
is that what you're trying to achieve?
(with-transaction [db-spec db-spec] (execute! db-spec ,,,))
And the new
:single-key-in linter flagged a bunch of stuff in our code too so "yay!" on that as well!
t-con was an unused binding -- correctly -- which is a bug because the wrapped code should use the transaction not the original db spec.