I really wish people would learn SQL instead of learning all the languages/tools that write SQL for them. Why are we abstracting this from ourselves? Is it really that hard to write some set based operations?
Yo - my message probably seems like a downer then, and I apologize for that. I’ve just seen so many ORMs and query builders and other things come and go. And it frustrates me when people want to learn the new hotness rather than learning how to do the thing. Especially when the thing in this case is SQL, the most widely used language for database interaction.
The way I perceive PRQL is somewhat like SQLAlchemy-Core (the SQL expression layer, not the ORM). Almost a 1:1 mapping to SQL but softening the rough edges in SQL when constructing more complex queries dynamically, in particular: no function calls, no real variables, only string concatenation. While SQLAlchemy-Core lets you even extract sub-queries into variables, I don’t know about how powerful PRQL is in this regard.
From what I see from the docs I’m rather hopeful though.
@dark_stang@seasonone as someone who uses both: abstraction is mostly about (a) cross-compatibility (making one command work across multiple different database backends) and (b) interfacing more naturally with code to reduce the work needed to make changes
ooo, I love this. It reminds me of how nice C#'s LINQ is…
“Pipeline style” DB queries have some interesting advantages as well:
It’s straightforward to write efficient queries for DBs that don’t include a query optimizer stares at Datomic
You can split the pipeline into server-side and client-side steps when working with less capable DBs stares at most of NoSQL
It would be much easier to transition from a pipeline API to a non-text-based API so that our ORMs/query builders can directly talk to DBs without the overhead of generating and parsing SQL.