Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-02-03

Channels

#honeysql
<
2021-02-03
>
seancorfield00:02:30

(writing documentation is taking me longer than I'd hoped so I'm not going to cut an alpha release to http://clojars.org just yet -- but folks are still welcome to try it out via {:git/url "" :sha "4cbeb170ddf4ba0d7238c43b092ffb0a33062474"} 🙂 )

seancorfield19:02:21

If anyone does take v2 for a spin, please provide feedback -- good or bad.

dharrigan19:02:15

Hi Sean. I plan to do a bit of playing around in the next few days with it. Slightly busy at work atm.

dharrigan19:02:43

Hopefully I'll have positive feedback 🙂

markaddleman21:02:00

@seancorfield Where did you land regarding spec and v2? Personally, I'd love to have a honeysql spec. I do a lot of programmatic SQL generation and transformation. I believe that having a spec will help create a honeysql AST that will make transformations easier.

seancorfield22:02:08

@markaddleman Still on the roadmap but it's much harder than I initially thought -- since it's basically the Spec equivalent of SQL's entire syntax 🙂

markaddleman22:02:39

ha. Yeah, that was the conclusion I came to. I was hoping you had some magic up your sleeve

seancorfield22:02:57

Writing a Spec that just says "this data structure is acceptable to HoneySQL" is fairly tractable but that's very lax -- HoneySQL can format all sorts of otherwise rather dubious "SQL" 🙂 No guarantee the SQL itself is valid, however...

seancorfield22:02:03

Since I want v2 to accept as much of the existing data structure DSLs out there which are used by v1, there are some inconsistencies I don't want to fix. At the same time, I've made v2 a bit more lenient in some cases where there's no ambiguity.

seancorfield22:02:43

For example, (format {:select :id :from :table :where [:= :x 42]}) works in v2 because it makes sense -- folks expect that. But if you want aliases, you can't just do (format {:select [:id :a] :from [:table :t]:where [:= :x 42]}) because both :select and :from really expect sequences of identifiers and aliases need to be nested inside that sequence, as (format {:select [[:id :a]] :from [[:table :t]]:where [:= :x 42]})

seancorfield22:02:18

There's no good way to consistently make the "mistake" genuinely illegal without also prohibiting strange-but-legal stuff...

seancorfield22:02:30

I certainly could make v2 stricter (and disallow '{select id from table where (= x 42)}) but it would also make it more complex and probably less easy to use 😐

seancorfield22:02:03

(and v2 deliberately accepts symbols and lists where v1 only accepted keywords and vectors -- because folks want the quoted datalog-style query format)

markaddleman22:02:47

Understood. I encountered similar issues. I author queries by hand using using honeysql's syntax but the very first thing my transformation system does is "normalize" it (eg, all column projections have aliases, all tables have aliases, where clause expressions are converted to SqlCall records, etc).

markaddleman22:02:49

I despair of writing a spec for the unnormalized structure but the normalized data wouldn't be too bad

seancorfield22:02:43

For example, (format {:select :id :from :table :where [:= :x 42]}) works in v2 because it makes sense -- folks expect that. But if you want aliases, you can't just do (format {:select [:id :a] :from [:table :t]:where [:= :x 42]}) because both :select and :from really expect sequences of identifiers and aliases need to be nested inside that sequence, as (format {:select [[:id :a]] :from [[:table :t]]:where [:= :x 42]})