Fork me on GitHub
#sql
<
2016-08-03
>
ricardo08:08:32

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

ricardo08:08:05

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.

ricardo08:08:11

I just find writing queries directly for HugSQL less clunky than

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

sandbags11:08:49

@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.

ricardo11:08:37

@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.

sandbags11:08:10

yep that makes sense

ricardo11:08:46

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.

sandbags11:08:17

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

sandbags11:08:28

i look at your example above and think it looks good

sandbags11:08:51

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

ricardo11:08:17

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

sandbags11:08:23

i wonder if there is a link to art here also

sandbags11:08:32

do you have any views on Kandinsky or Klee?

ricardo11:08:22

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

sandbags11:08:37

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

ricardo11:08:47

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

sandbags11:08:47

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

sandbags11:08:09

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

sandbags11:08:22

my mind immediately went to abstract art

ricardo11:08:33

Oh. You didn’t mean some Clojure library.

sandbags11:08:46

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

ricardo11:08:49

Actually Kandinsky. 🙂

sandbags11:08:59

that was me omitting some necessary context there

sandbags11:08:03

a terrible habit of mine

sandbags11:08:25

it drives a number of people i work with nuts

sandbags11:08:34

fortunately they are forced to put up with it 🙂

ricardo11:08:38

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.

sandbags11:08:11

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

sandbags11:08:24

can’t hurt to know both approaches

ricardo11:08:34

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.

sandbags11:08:52

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

sandbags11:08:13

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

ricardo11:08:54

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. 🙂

bja20:08:09

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.

bja20:08:30

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

bja20:08:34

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

mattly23:08:40

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

mattly23:08:43

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

mattly23:08:36

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