TBH, this is pretty straightforward stuff compared to a lot of the conditional query building we have to do at work where we have cond-> and a big pipeline of conditions and DSL-builder function calls, that each may add select, join, where, having, etc clauses 🙂

Just saw this! Sorry for the delay. So most of our cases around this look something like:

{:where [['and
          '[= tx.type "SalesOrd"]
          '[in tx.status ["B" "D" "E"]]
          '[= tx.custbody_3pl_exported "T"]
          ['in 'so.location (map loc-id
                                 [:
                                  :])]
          ['in 'tx.custbody_sm_order_source
           (map source-id
                #{:
                  :})]]]}

Okay, that wasn't the "unquoting" I was imagining, so thanks for clarifying and providing feedback. I'll respond in more detail tomorrow when I'm at a computer instead of on my phone!

@potetm Gathering my thoughts: > My personal problem is the constant SHIFT-; motion when typing the query. Yes, good point, and that's why I'd like to make the quoted-symbol DSL easier to use. > I would prefer a {:params [arg1 arg2]} addition to the option map over the var args option Yes, I'm not very happy with the var args option either -- but formatf also requires you use ?1, ?2, etc and "fakes" the map of params with (zipmap (range) param-vals) so it's as if you had {:params {:1 arg1 :2 arg2}} and the point is to save you the keystrokes (and, of course, they have to be keywords right now which raises the typing issue again. Perhaps (sql/formatf 'dsl [arg1 arg2] {opts}?) might be good compromise here instead? No var args but you'd have to wrap a single arg as a sequence. At least that would allow for (sql/formatf 'dsl {opts}) since the second arg could be either sequential (arguments) or not (options hash map). I wonder what your thoughts on the new formatv function? That lets you specify local bindings that should be substituted as values into a quoted-symbol DSL. I guess it depends on how often you would "unquote" just a local symbol vs an entire expression...

Yeah (sql/formatf 'dsl [arg1 arg2] {opts}?) seems like a good option here. I'm actually struggling to find any instances in the codebase where formatv would be useful. We use honeysql almost exclusively for building queries. If we have a simple sql statement, we usually just write the sql. This often means that query fragments get passed across scopes, so any scope-based solution is gonna be difficult to use. Actually, now that I say that out loud, having named parameters would be necessary in some contexts. (Or I would just fall back to manual quoting in those instances. This is actually the most likely outcome if I'm honest.)

That's good feedback, thanks!

If there are situations where you need to "drop down to the data dsl" that you think could be simplified with extra helpers or smarter helpers, LMK.

There is one super edge-case thingy where you have several CTE’s and at least one of them is recursive. I think that’s hard to express with the helpers.

It might also have been me…

I don't have much (any!) experience with CTEs so it's entirely possible that area has some rough edges. I'm still on Percona 5.7 at work and nearly all of my database experience has been MySQL (with a bunch of -- OMG! -- Oracle before that while at Macromedia, before we switched to MySQL).

Oracle - the good old days 🙂 One thing I remember with fondness of oracle was that they had a dashboard where you could see all kinds of interesting stats. I miss that.