Fork me on GitHub

thanks for the help @seancorfield I have another variation of this problem. If :?path is a vector and I want to unpack the vector inside my formatter e.g.

;; better syntax for path:
(sql/format {:select [:*]
             :from [:honey]
             :where [:-> :data :?path]}
            {:params {:path ["key1" "key2"]}})
;; => ["SELECT * FROM honey WHERE DATA->?" ["key1" "key2"]]  <<<-- wrong
;; desired
;; => ["SELECT * FROM honey WHERE DATA->?->?" "key1" "key2"]  <<<-- desired
I have the code for this here does this make sense or I would need necessary to pass the vector elements separated as params? [:-> :data ?:key1 :?key2] (as this is a path, I thought sending a vector would be better imo)


@iagwanderson Bear in mind that, in general, the argument to a formatter can be a completely arbitrary DSL expression and could render to just SQL or to some SQL and an arbitrary number of parameters (because the expression could be arbitrarily complex). I don't think your mental model of how formatters work lines up with reality at the moment 🙂

😅 2

In the second example here the :a value could be an arbitrary SQL expression and the only thing that :betwixt operator guarantees is the "order" that these arbitrary SQL will be placed related to the other 2 parameter values.


this is how I should read this example?


Yes, that's why there are three format-expr calls and then the SQL and the params are assembled into the result:

(let [[sql-a & params-a] (sql/format-expr a)
                          [sql-b & params-b] (sql/format-expr b)
                          [sql-c & params-c] (sql/format-expr c)]


got it! leaving the named parameters aside, I am thinking if the approach of the :-> operator is useful or not. I am working a lot with jsonb columns and was exploring some ways to make it more honeyql-like 😃 instead of using raw calls


I'm not familiar with that operator but it doesn't seem like you need anything custom for it:

dev=> (sql/register-op! :-> :variadic true)
dev=> (sql/format-expr [:-> :data :a :b :c])
["data -> a -> b -> c"]


Is that what you're trying to produce?


Formatters do not have access to named parameters. By design. And that's because any expression in the DSL can expand to SQL with zero or more parameters -- and the parameters vector is only fully known once the entire DSL "statement" has been processed, and the top-level formatter then processes the :params hash map (to unwrap the placeholders that are put into the parameter slots by the formatters).