Hacker News Reader

Comment by gleb | Hacker News Reader

I think somebody needs to actually justify the need for composable SQL. With examples. It's far from obvious.

In my experience outside of extension code the need for composable SQL is very limited. Most uses cases can be satisfied by Rails 2 scopes.

Now, if composability was free - sure it's great. But it's not free.

So, on one hand:

* it would be nice to have infinitely composable SQL

On the other hand:

* it would be nice to just have the actual SQL with all the features, well understood syntax and semantics that cost decades and billions of dollars to develop

* and no wrapper-on-top-of-SQL limitations and translation bugs, and need for training

With these language-on-top-of-SQL you don't get both. In fact you get severe compromises in the second group.

View on HN

User-generated data in a user-defined schema, where the user wants an Excel-autofilter-like sorting and filtering experience over rowsets that range from 10 thousand to 3 million rows, and 2 columns to 150 columns.

Columns may be sorted and filtered individually or in combination. Filters may be based on value set membership or range criteria, comparisons with fields in the data or via a join to other tables, or based on the presence of an entry in a join table (think: tags or labels, and you want to filter by presence or absence of tag).

(This is what I spent the past couple of months implementing. The simplest way of composing SQL is via union / except / intersect, but it's also the worst performing; doesn't work great past a few hundred thousand rows. And you still need to compose together the filter conditions into a where clause.)

Rails 2 scopes are literally the case for composeability...

Yes, but a very limited one.

I'd love to see a solution with tradeoffs made the other way:

  * syntax and semantics 99% like underlying SQL
  * support for 99% of underlying DB functionality
  * traditional areas where ORMs add value:
    * deserialization into convenient data structures
    * casting, quoting and escaping on the way in and out
    * using stored association metadata for concise joins in the query

Every single one of those bullet points is a primary design goal of Diesel (caveat: Our semantics generally map to PG, because they apply well to other backends and are the least nonsensical)

Reply on news.ycombinator.com