Have completions been implemented at all? The language looks like it is designed to take that into account, but I don't see that after a cursory search
PRQL: Pipelined Relational Query Language
151–160 of 214 posts
Re: PRQL: Pipelined Relational Query Language
#152So, in principle, how is this different approach than DBT?
dbt is a tool for defining and orchestrating in-database transformation jobs. Typically you write SQL statements to define the transformations (plus some template language to pull in additional context if needed).
PRQL is an alternative language for writing queries which compiles to SQL. There is a dbt plugin which presumably allows you to define the transformations in PRQL instead of SQL, while everything is still orchestrated by dbt.
Re: PRQL: Pipelined Relational Query Language
#153Has anyone compared PRQL and Malloy head to head?
Re: PRQL: Pipelined Relational Query Language
#154Earlier quoted context omitted.
It’s certainly not a feature. A lot of important SQL usage is ad-hoc queries, and they are more annoying to type than they should be.
I don’t understand how changing the order of the clauses makes a query easier to type.
If you have auto-complete it can see what table you are using and complete the column names. Starting with SELECT it could be any column in the database.
Re: PRQL: Pipelined Relational Query Language
#155There is a point in moving the FROM ahead of SELECT and getting sensible auto-complete suggestions from your IDE as you type.
LINQ, however, attempts to solve a much bigger problem: Use consistent code to process data and don't worry whether it is in a remote database or in a local array.
If you manage to do it in a way that
- integrates seamlessly with e.g. Python IDE and I don't have to pass and parse strings
- allows me to access graph, document and relational data
- allows me to pull and process the data from REST APIs, [O/J]DBC and straight from my RAM
- and maybe even includes deductive (PROLOG/DATALOG) features
I will be your most loyal client
Re: PRQL: Pipelined Relational Query Language
#156This must not be missing here then: "I don't want to learn your garbage query language" [1] [1] https://erikbern.com/2018/08/30/i-dont-want-to-learn-your-ga...
Big fan of this post! We link to it from PRQL website. Our goal for PRQL is a great language to integrate with & build on. So we don't have N languages for N databases. Because PRQL will always be open-source, and won't ever have a commercial product, we think that's much more feasible than a DB-specific or product-specific language. (PRQL dev here)
As evidenced from the poster's ORM rant, two languages for the same DB seem just as offensive to them as different languages for different DBs. I suspect you're still going to have an uphill battle converting them, unless they were hit with a blinding shaft of sunlight on the road to the SQL History Museum or something.
Re: PRQL: Pipelined Relational Query Language
#157Earlier quoted context omitted.
I don’t understand how changing the order of the clauses makes a query easier to type.
If you have auto-complete it can see what table you are using and complete the column names. Starting with SELECT it could be any column in the database.
I see this complaint stated over and over again, how hard is it really to type SELECT * FROM x a and then go back?
Re: PRQL: Pipelined Relational Query Language
#158The limitation of PRQL is that it only does SELECTs, by design. If you want to insert/update/delete data, you're back to SQL. That means that your team's data scientist might give you a query written in PRQL, but if you want to actually incorporate it into the data pipeline, you'll need to translate it into SQL. I wish that PRQL would support at least a limited ability to insert -- for example, maybe just the case of…
I don't see why PRQL can't support data mutation. Just have an insert/update/delete operator that must go at the end of a pipeline, and which takes a table name as an argument. An SQL query like this: UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' Could then be written in PRQL as something like this: from counters filter startswith(name, 'prefix.') derive { new_value = value + 1 } select { name, new…
This feels way less intuitive than SQL:
UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%'
Re: PRQL: Pipelined Relational Query Language
#159Earlier quoted context omitted.
Here are examples of MongoDB aggregations: https://github.com/ClickHouse/ClickBench/blob/main/mongodb/q... They are painful to write compared to SQL queries. Although the commercial version of MongoDB has support for SQL, it's not available for general MongoDB users.
Thanks! Those do look awful and more what I remember from the brief period when I used MongoDB in around 2013 or so. I take it GP comment was just trolling then?
I was not trolling, I actually dislike MongoDB aggregation syntax and it seems like PRQL is something that could potentially replace it or go on top. Admittedly I only took a quick glance at PRQL though, so perhaps I misunderstood something or it's not applicable to this case.
There are examples on Mongo's page, eg https://www.mongodb.com/docs/manual/core/aggregation-pipelin...
eg:
db.orders.aggregate( [
// Stage 1: Filter pizza order documents by pizza size
{
$match: { size: "medium" }
},
// Stage 2: Group remaining documents by pizza name and calculate total quantity
{
$group: { _id: "$name", totalQuantity: { $sum: "$quantity" } }
}
] )Re: PRQL: Pipelined Relational Query Language
#160Earlier quoted context omitted.
I've had two real gripes with SQL. The rest of it has been, as you said, pretty good. Complaint 1: Not being able to use selected columns later in the same select. SELECT gnarly_calculation AS some_value, some_value * 2 AS some_value_doubled Instead: SELECT subquery.*, some_value * 2 AS some_value_doubled FROM ( gnarly_calculation AS some_value ) AS subquery Complaint 2: Not being able to specify all columns except .…
Both complaints are resolved by ClickHouse. This video also covers many other advantages of ClickHouse's SQL dialect: https://www.youtube.com/watch?v=zhrOYQpgvkk Some may find your first complaint questionable... But I specifically designed ClickHouse SQL to allow aliases to be used and referenced in every part of SQL query.
So unsurprisingly based on my gripes, we are an OLAP shop. I've never heard of ClickHouse before, and I'll be looking into it. We're doing OK on PostgreSQL, but just OK. A lot of learning and unlearning.