@sandbags: For me… it’s mostly that I see fairly little difference between writing a bunch of Clojure keywords, and just writing SQL.

Maybe if I was doing more runtime query building, or if portability was a major concern. But neither has happened for any recent use cases.

I just find writing queries directly for HugSQL less clunky than

(sql/build :select :*
           :from :foo
           :where [:= :f.a "baz”])

@ricardo: i can see your point although I like donaldball’s comment that Honeysql is an AST for the common 90% of SQL and would prefer to manipulate that AST than muck about with appending & subbing strings.

@sandbags: Sure, if you have to do run-time query building, I agree. But for my use cases, query composition through snippets has been more than enough.

yep that makes sense

Just giving an example of why someone would forgo Honeysql. I feel writing pure SQL is less clunky for 99% of cases, and snippets read very similar to Honeysql when I need something like it.

i guess as much as anything this might be a matter of taste

Indeed.

i look at your example above and think it looks good

but my own tastes run somewhat to the abstract rather than the detailed 🙂

Yeah, full disclosure: I was strongly infatuated with Khorma for a while there. 😛

i wonder if there is a link to art here also

do you have any views on Kandinsky or Klee?

But I also get tooling and validation when writing SQL queries for HugSQL, which I don’t get with either of the other approaches.

hrmm… there’s another dimension i guess, I will have a look at HugSQL

Re Kandinsky and Klee: hadn’t heard of them actually.

@sandbags: http://www.hugsql.org/

it’s probably rather a stretch to think in these terms

it just occurred to me that if taste is involved that there may be other indicators

my mind immediately went to abstract art

Oh. You didn’t mean some Clojure library.

(but this intertwines a number of other psychological factors which may have no bearing on the world of code)

Actually Kandinsky. 🙂

heh

sorry

that was me omitting some necessary context there

a terrible habit of mine

it drives a number of people i work with nuts

fortunately they are forced to put up with it 🙂

Oh, another thing… When using DB-specific features - say, Postgresql’s full-text search, or JSONB, I found the more abstract approaches fell short, and I had to end up to embedding SQL on the high-level query.

cool, you’ve definitely persuaded me to take a look at the HugSQL approach (thanks for the link)

can’t hurt to know both approaches

That grew old fast. It was cleaner to just write the query in pure SQL, then ask HugSQL to make a nice interface to it for me.

i’ve been debating whether to defrecord types for my entities or just live in the world of plain maps

the last time i made this decision (writing a CES) i opted for records as i thought it was “cleaner” and then later walked back on it

Re Kandinski: My tastes run more towards the Gustav Klimt or Giuseppe Arcimboldo, in case you want to read something into that. But that’s getting off-topic. 🙂

I do a lot of query building and HoneySQL has been very nice. I gave a talk on it and did mention that if your use cases aren't dynamic, then HoneySQL probably isn't right for you.

but I use a bunch of postgres-specific functionality and HoneySQL is great for that

and I write SQL nowhere (except for my DDL migrations)

HoneySQL has worked very well for my -- extremely dynamic -- query needs

I have one primary query but it ropes in anywhere from 1-12 joins and any number of arbitrary conditions or group clauses

with about 100 lines of clojure I've managed to replace ~1000 lines of spaghetti ruby