Fork me on GitHub
#off-topic
<
2018-07-18
>
leblowl02:07:58

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

curtis.summers10:07:36

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,...)

leblowl06:07:20

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

bja11:07:21

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 [email protected])
       (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?

dominicm11:07:14

> laziness > writes a macro Nope. Definitely not laziness.

dpsutton12:07:23

i believe that is pythonic.

dpsutton12:07:27

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

dominicm12:07:15

I suppose you could actually just throw from the doseq too, that's a perfectly valid form of control flow

3Jane13:07:14

> i remember hearing end of an iterator is found by catching an exception It is. I felt my mind break when I heard that -.-

bronsa13:07:34

i don’t particularly mind exceptions to backtrack

bronsa13:07:06

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

tbaldridge13:07:45

And in python exceptions are return values anyways, so it’s six of one half a dozen of the other.

dpsutton17:07:30

fun thing to debug. (filter #(fn [coverage] (stuff about coverage)) in a threading macro. always returned true. took a second to figure out why

😂 8
eggsyntax17:07:30

I didn't see it until I got curious and started trying to type out a simplified version 😜

dpsutton17:07:09

likely only a bug in js which just does not care about arguments given to a zero arity function.

ddellacosta17:07:51

too bad Clojure isn’t statically typed

eggsyntax17:07:57

Yeah, it throws an ArityException in the clj repl