Clojurians Log v2

🙂

Converted my application to honeysql v2

slowly working through it to find any breakage

I notice now that function calls are uppercased, i.e., in honey v1, [:ST_SetSRID....] now becomes ST_SETSRID(... when formatted in honey v2

(just an observation, natch it's fine as sql is case insensitive unless quoted)

Modified about 15 files that used honeysql calls, so let's see what happens 🙂

I am liking the natural use of [:foo being a function call

Re: uppercase -- yeah, v1 was a bit inconsistent about that, depending on how it treated the context so you'd get lowercase for some things that were clearly built-in and "should" be uppercase, you'd get mixed case in some situations, and then you'd get uppercase for other things 😐 So I just took the position that your own "vars" (tables and column names) should be left as is (modulo the - -> _ thing) and pretty much everything else should be uppercase.

consistency is key! 🙂

Having to wrap things in (sql/call ..) in v1 was probably the most common thing I got support questions and GitHub issues about: because [:foo 1 2 3] worked in "most" situations but there were lots of edge cases where it didn't quite work and you needed to "help" HoneySQL figure it out. And that's why I went with all the other "special syntax" as plain "function" calls too: raw, inline, param, etc.

(I'm going to make coffee and feed cats but will be back to answer any Qs in 10 mins)

(back)

I think it's looking good, question.

how does the on-conflict, do-nothing work (previously I was using a defhelper to default a clause)

Figured it out

Man, working with the repl, rich comment blocks is fantastic, such quick feedabck

(on-conflict (do-nothing))

(insert-sql {:id 1}) ;; ["INSERT INTO investigation (id) VALUES (?) ON CONFLICT DO NOTHING" 1]

(as an aside, conjure on vim recently gained the ability to put the evaluation into a comment beside the form - that's what you're seeing there - makes capturing the result of a RCF fantastic and easy to look back upon)

Well, so far so good, the happy path of my application works with honey v2

will check over the data in due course

Nice. Yeah, I haven't documented the helpers yet -- even tho' I prefer those over working with raw data -- but, as you're finding out, they're a lot more comprehensive than in v1 (there is literally a helper now for every single clause -- and a couple of helpers for special syntax forms as well).

Once I've finished implementing all the parts of nilenso/honeysql-postgres I'll add a specific section to the docs that talks about the differences between HoneySQL v2 and that lib -- there are a few things that just made sense to do a bit differently @dharrigan

np, looking forward to it. So far, the upgrade has been relatively straightforward. The main thing for me was replacing "sql/call" and "sql/raw" statements

will do some testing over the weekend, apart from some temporal differences, the data produced v1 vs v2 should be the same

Much appreciated! I will continue working on the docs over the weekend, after completing the PG DDL stuff.

so far, data produced is identical, apart from a datetime stamp (of creation)

encouraging! 🙂

the two results are about +135,000 lines long, comprised of various sql reports, so only 2 lines differ, and that's the date of when the request to generate the reports was done 🙂

Sounds like some serious testing -- thank you!

more testing adhoc over the weekend on the CD of CRUD actions 🙂

oh and U too 🙂

It should now support stuff like delete from multiple tables, delete using, insert into as, and various other stuff that v1 omitted (or had only partially added).

It also has all the OVER / PARTITION BY / WINDOW stuff built in now.

my inserts do various joins over several tables

and my reports do use OVER window functions too, so that appears to be tickity-boo for me atm

I've replaced all the honeysql-postgres extensions from nilenso too

right, ttfn! off to re-re-re-read LOTR!