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
deleted by creator
As a developer of the compiler from prql to sql, I can say that I’m working on a new language because I know SQL quite in-depth.
It seems ok on surface, but there are many inconsistenties that you either learn to live with or don’t even know are there until they trip you.
deleted by creator
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.
No biggie, it a nice entry barrier to have, because nowadays, there just too much new frameworks and languages and crypto currencies.
I don’t get it either, I don’t feel it’s difficult to learn. Personally I very much enjoy writing SQL. It’s satisfying.
@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