Really intriguing article about a SQL syntax extension that has apparently already been trialed at Google.
As someone who works with SQL for hours every week, this makes me hopeful for potential improvements, although the likelihood of any changes to SQL arriving in my sector before I retire seems slim.
I just threw up in my mouth a little. Do we have content warnings here? We should get content warnings here. It's been three blessed years since I thought about the pile of crap that is LINQ. Here's to three more!
In Clojure, -> is used for inserting the piped argument at the head position in the arguments of whatever it is passed to, while ->> is used for inserting it at the tail. This approach is great for working with immutable data in a series of approachable transformations, which I believe is one reason why so many Domain-Specific Languages for generative programming are written in that language, aside from its interactive REPL. Additionally, there is no need to worry about excessive copying, as this is generally well optimized.
This can be particularly useful with HoneySQL, which is more of a DSL for SQL rather than a typical ORM tool. For example:
(defn apply-filters [query filters]
"applies WHERE clauses to a query"
(reduce (fn [q [column value]]
(helpers/where q [:= column value]))
query
filters))
(defn build-dynamic-query [{:keys [table columns filters sort-by limit]}]
(-> {}
(helpers/select columns)
(helpers/from table)
(apply-filters filters)
(helpers/order-by sort-by)
(helpers/limit limit)
sql/format))
;; Result - a super readable function call that resembles a natural language
(build-dynamic-query
{:table :products
:columns [:id :name :price]
:filters {:category "electronics" :in-stock true}
:sort-by [:price :desc]
:limit 20})
The reorganization of statements is excellent but the pipe operator itself is unnecessary and annoying. It'd be far better to just rearrange the clauses and call it a day, relying on the keywords that are still present to signify clause termination...
Especially once we get into subqueries and CTES, I never want to write:
|> LEFT JOIN |> FROM foo |> GROUP BY clusterid |> SELECT clusterid, COUNT(*)
ON cluster.id = foo.clusterid
And I'm also not splitting out a trivial subselect like that into four lines because I respect my reader.
I lile this a lot. This reminds me a lot of KQL (a microsoft query language that's used for a bunch if azure logging).
I use a lot of python pandas/dask- I've definitely got used to viewing a table as a series of operations to perform rather than the kind of declarative queries you get in SQL.
At what point is it no longer SQL? If we're changing fundamental stuff, I'd love a way of writing loops or if statements that isn't painful too.
Stored Procedures have been a thing for literally decades. But they're an absolute pain.
What would really improve the usefulness of databases are autoindexes and generally more "let me handle that for you". I'd argue 90% of business apps essentially need a way to store objects and their relationships, but doing that in an efficient manner is really hard (at least if you've got a few more rows to handle).
I'm not sure I'm convinced by their reasons for not creating a new language (i.e. PRQL). I used it a bit and it was fantastic. It has support for using raw SQL if you need to access really niche features.
Really the only problem is that it doesn't support mutation, or database-specific features (but you can use the raw SQL escape hatch in that case).