But why would I, what can it do, that Ecto can’t?
1 Like
It’s simply a language designed for data scientists/analysts
Ecto can do anything with SQL, and PRQL cant insert/delete/update data. It’s for data analysis.
To make life much easier for data scientists/analysts, it provides a modern language 
Hope this clear any doubts
sorry for being stupid. How is it making life much easier? Can you give an example of a query that is easier in PRQL than in Ecto? If I look at the examples at the homepage, I think that those would all look similar in Ecto (or do they, me = complete Ecto-n00b).
As I said, it’s not even competing with Ecto
You need to compare it with SQL, there is a playground to try out.
It just makes it easier to write SQL statements in a more friendly language.
I don’t know how to explain further, it’s just a tool and it does not compete with Ecto at all.
My intended idea was to introduce PRQL for Livebook in a friendly manner. This was the first step towards it.
(Mainly for data scientists/analysts)
It’s still young, but it will improve over time.
I hope it will also help bringing data scientists/analysts to elixir world as well
So this is compared to SQL, not Ecto?
If its a tool to query databases, it does compete with Ecto, because Ecto can do that as well.
Yes
You can then say Postgrex also competes with Ecto since you can do queries with it also
OK, I’d use Ecto, because its simpler. Why would I use PRQL over Ecto to query? (sorry for being a pain, I have a query intensive app at hand, one could say data analysis, and I want to pick the right tool).
I would recommend writing SQL queries with Ecto for now. PRQL is quite young and still in early development. We are targeting getting feedback to improve the project.
So in your scenario i would prefer using Ecto, since this is a production app.
1 Like
PRQL seems more of a competitor to sql for writing quick one off queries to explore a dataset than it is a competitor for sql in application development.
1 Like
So that we’re all on the same page I think we can all agree that it’s easy for us to say “Ecto” and mean fairly different things depending on context. Ecto is a framework bundling together a number of data handling tools. Insofar as this discussion is concerned anything I say now (or previously for the most part) should be construed as referring to the Ecto query DSL and not necessarily Ecto more broadly.
I would say that it does. Raw SQL through Postgrex (or RDBMS of choice), the Ecto query DSL, and PRQL… all are options for how you’d write queries for database data. Early in my current project I was set on using raw SQL through Postgrex and only using Ecto for internal data validation (like form data validation). I found, however, that Ecto’s query DSL was superior for my needs since it worked naturally in my other Elixir application logic: Ecto query DSL won over raw SQL & Postgrex (for most tasks). Ecto query DSL and PRQL is in the same way competitive: you’re most likely going to choose between one or the other… sure you might use the other parts of Ecto with PRQL… but mixing PRQL and Ecto’s query DSL doesn’t seem sensible.
From the the application development perspective, which I took as the context of the original question, I don’t think PRQL makes sense compared with Ecto’s query DSL. PRQL would be in the same class as the Postgrex/raw SQL type solution with (perhaps) a nicer language than SQL; it would still be at a substantial deficit to Ecto’s query DSL and what it allows you to accomplish given that rather seemless fit with other regular Elixir code. But this brings me to…
That’s a different scenario than the application development perspective. I do think, assuming that PRQL is sufficiently superior to SQL in this context, that it’s a reasonable thing to have available and to consider using. Livebook style usage was not the purpose I understood as being considered at the start of the discussion, but this makes it clearer what the intent of introducing PRQL to Elixir is aimed at and is helpful in this discussion.
As someone that has worked with data and databases for some time, not just as a developer but a lot of data analysis work as well, I will tell you that I’m a bit skeptical of PRQL itself from what I’ve seen. Before I’d encourage it’s adoption for any use case, it has to be so much better than SQL that the cost of abandoning the industry standard and everything an industry standard brings with it is worth it. Looking at PRQL I’m not sure that it’s fundamental design is that kind of improvement; it’s different and solves some SQL problems, but I don’t see it reducing overall complexity as much as offering a similar level of complexity on its own terms. Moreover, because you’re compiling down to SQL in the end you’d still need to know SQL to troubleshoot something going wrong. This doesn’t appear to be an issue of features lacking from early releases as much as fundamental design. It may, in fact, be making the same mistake as early SQL did:
When Ray and I were designing Sequel in 1974, we thought that the predominant use of the language would be for ad-hoc queries by planners and other professionals whose domain of expertise was not primarily database management. We wanted the language to be simple enough that ordinary people could “walk up and use it” with a minimum of training. Over the years, I have been surprised to see that SQL is more frequently used by trained database specialists to implement repetitive transactions such as bank deposits, credit card purchases, and online auctions. I am pleased to see the language used in a variety of environments, even though it has not proved to be as accessible to untrained users as Ray and I originally hoped.
– Donald D. Chamberlin; “Early History of SQL”; Early History of SQL | IEEE Journals & Magazine | IEEE Xplore
So SQL’s original intentions were the same as what I gather to be that of PRQL team. Clearly team PRQL thinks they failed, but are they really addressing the core issues that prevented it from analyst level use? I could very well be wrong in betting on PRQL missing that mark as well and I do wish the best to the PRQL team and advocates in their efforts to problem me wrong.
4 Likes
Hi team!
This discussion came across the PRQL discord. I started the PRQL project and have been working with @kasvith who’s added Elixir bindings recently.
I’m grateful for the discussion here! I thought I’d add a couple of points that will hopefully help contribute:
-
We’re not trying to compete with Ecto. Ecto has been listed as one of our inspirations since the start of the project; check out our FAQ. For every million data queries written, I’m guessing something like 700_000 are in Excel, 250_000 are in SQL, 1_000 are in Ecto, and 100 are in PRQL. So Ecto is not the language we’re attempting to displace…
-
Without having enough Ecto experience, my understanding is similar to @LostKobrakai 's — PRQL’s focus is on analytical queries rather than transactional queries, and so probably has even less competitive overlap.
-
If someone has an existing Ecto project, or a team that knows Ecto, I would definitely not suggest that they abandon Ecto for PRQL. But if folks want a composable & concise language to write analytical queries with bindings to languages as diverse as JS/Python/Java/go/Rust, and compatibility with a whole range of SQL dialects, then PRQL could make a good option.
-
One meta-comment, if that’s reasonable as a tourist here — I would encourage folks to be thoughtful before dismissing new projects. If PRQL is bad, then calling it out for being bad is act of service to both the discourse and PRQL itself. But there’s a bunch of sarcasm above about how “If only modern SQL would have some syntax to fetch
Nrows with ties, oh wait, it does:” that’s based on a fairly basic misunderstanding of the generated SQL (thanks to @LostKobrakai for pointing that out). Our comments have the power to encourage folks like @kasvith to continue making open-source contributions; the status that’s conferred from communities is often a helpful motivator. And I’d claim contributions which enable communities like Elixir’s & PRQL’s to collaborate have a strong positive benefit.- Back to the object-level: PRQL can represent the simpler query with just
from employees | sort join_date | take 1, FWIW.
- Back to the object-level: PRQL can represent the simpler query with just
Hope that’s reasonable. If you have any feedback on PRQL, please post an issue or @ me here, and we’ll gladly respond. Thank you in advance, and I hope we continue to get the chance to collaborate.
Max
10 Likes
I would encourage folks to be thoughtful before dismissing new projects.
True, let’s see the result.
I am very skeptical too myself, because PRQL seems this battery included product, that shortly will outlive its usefulness. The other point that is more concerning is having PRQL on top of SQL, this introduces a big layer of complexity into play, should something go wrong and you will have to debug at both levels.
You have that problem with every layer of abstraction. Same with Ecto or anything else, which tries to integrate with SQL based databases, but doesn’t want to deal with sql (directly).
3 Likes
True, however ecto was never meant to replace SQL, witch PRQL claims, because as far as I understand this is targeted to people that don’t want to invest their time in learning SQL.
Is that necessarily a problem though? SQL can get pretty ugly at times and not everyone writing SQL is a developer or that way inclined. If it makes analytical queries easier for some end users then hooray?
It’s not true, it’s just to make your life much easier.
Its targeted audience is people who deal with SQL every day, for analytical purposes.
SQL can get pretty complex and add an extra term of complexity when dealing with data analytics, PRQL tries to smoothen that out by providing a modern language that compiles to multiple SQL dialects(portable)
2 Likes
SQL can get pretty complex and add an extra term of complexity when dealing with data analytics
This doesn’t seem to make much sense, SQL can get complex, however that is due the fact that there are complex selects, I don’t see any ways it can become easier while having the same level of control. Can you show a “complex” example in SQL and how it is much simpler in PRQL? also could you make a definition on what modern means in this context, because this word is used as every reply without any consistence.
1 Like
Yep, I think this entire thread boils down to this question.
Then it means this is just not true, otherwise if this tool was used by someone doing something more serious than toy projects we would have had our answer right away.
The conclusion this brings to me is that the only advantage this brings it’s battery included and portability.
The portability is still unclear at what cost, since at some point you will have to deal with SQL of the specific engine, because this is the same struggle that ECTO has, if you want some specific features that only postgres has, you have to write fragments, there is no way you can generalize different SQL engines that much.
