This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-18
Channels
- # aleph (4)
- # beginners (70)
- # cider (66)
- # clara (16)
- # cljdoc (20)
- # cljs-dev (9)
- # cljsrn (2)
- # clojure (36)
- # clojure-ecuador (2)
- # clojure-italy (14)
- # clojure-japan (2)
- # clojure-nl (22)
- # clojure-uk (79)
- # clojurescript (133)
- # clojutre (2)
- # code-reviews (5)
- # cursive (5)
- # data-science (1)
- # datomic (47)
- # duct (2)
- # emacs (1)
- # figwheel-main (3)
- # fulcro (11)
- # funcool (1)
- # graphql (6)
- # hyperfiddle (4)
- # leiningen (4)
- # luminus (9)
- # lumo (8)
- # mount (4)
- # nrepl (2)
- # off-topic (19)
- # onyx (1)
- # re-frame (23)
- # reagent (91)
- # reitit (17)
- # ring-swagger (2)
- # shadow-cljs (43)
- # tools-deps (27)
- # vim (45)
Anyone have any ideas for a simple implementation of named sql parameters in jdbc (using clojure.java.jdbc)? I am happy with plain sql and using clojure.java.jdbc directly, it's just difficult using only ?
's when you have a lot of parameters. I'd rather use select * from yo where foo = :id
than select * from yo where foo = ?
. I don't want to import another large library just for this feature. I am thinking of re-purposing HugSQL's parser (https://github.com/layerware/hugsql/blob/master/hugsql-core/src/hugsql/parser.clj) into a simple clojure.java.jdbc "pre-processor" so that it turns this ["select * from yo where foo = :id" {:id 1}]
into this ["select * from yo where foo = ?" 1]
... Curious if anyone else has solved this already before I dig into it
One level up from the parser is essentially what you're looking for (sqlvec functions): https://www.hugsql.org/#using-def-sqlvec-fns and its related functions: https://www.hugsql.org/#using-other-fns (see sqlvec, sqlvec-fn,...)
In case anyone is wondering, I found what I think to be a nice compromise to dealing with lots of parameters in JDBC queries (in between listing all the parameters after a long SQL string and parsing a SQL string to support named parameters). I decided to use nested vectors to visually minimize the scope of each parameter. I made a little gist: https://gist.github.com/leblowl/32bd62f1db3f1040ed1b530ee6a806df . Got the idea from http://funcool.github.io/suricatta/latest/#_the_where_clause
Is it pure laziness to use something like
(defmacro doreturn
"like doseq, but inject a function, (return x) into scope that takes any argument and exits the doseq, returning the x."
{:style/indent 1}
[& body]
`(let [~'return #(throw (ex-info "doreturn return" {::type ::doreturn
::value %}))]
(try
(doseq ~@body)
(catch clojure.lang.ExceptionInfo e#
(let [data# (ex-data e#)]
(if (= (::type data#) ::doreturn)
(::value data#)
(throw e#)))))))
to enable an imperative style with an early return instead of rewriting to use loop/recur or reduce?i remember hearing end of an iterator is found by catching an exception. if so you're in good company. but i wouldn't do this in "real" code
I suppose you could actually just throw from the doseq too, that's a perfectly valid form of control flow
> i remember hearing end of an iterator is found by catching an exception It is. I felt my mind break when I heard that -.-
it can be a very fast control flow mechanism on the jvm and I prefer it to passing sentinel values up the call stack to signal early exit
And in python exceptions are return values anyways, so it’s six of one half a dozen of the other.
fun thing to debug. (filter #(fn [coverage] (stuff about coverage))
in a threading macro. always returned true. took a second to figure out why
I didn't see it until I got curious and started trying to type out a simplified version 😜
likely only a bug in js which just does not care about arguments given to a zero arity function.
too bad Clojure isn’t statically typed