141–150 of 214 posts
How does this compare to EdgeQL?
This seems like just a compiler from a better language (PRQL) to SQL, while EdgeDB is actually a database that comes with not just a better language (EdgeQL), but also other great features (I love their TypeScript query builder or how incredibly frictionless the migrations are).
Earlier quoted context omitted.
While there's some stuff in C#/LINQ/EF that's more verbose (left joins are often a nightmare) or not-supported, I'll always say that I prefer writing queries in EF than in SQL, at least when dealing with SQL features that are supported by EF (which is a lot of them, it's a very expressive dialect). But EF lets you start with FROM, lets you do whichever keywords you need in whichever order (instead of WHERE -> GROUP B…
The downside though is you have to grab the sql it’s generating somehow to try to optimize it, figure out what crazy cross apply madness it’s going or to figure out why it’s blowing sql servers recursion limit. I prefer to avoid linq syntax now. It’s a false economy.
If you don't use linq you can't get EF entities anyway, and if you don't need EF entities you can can still use linq to get a projection and avoid the cross apply! The worst case scenario often ends up being writing a linq query to get your primary keys, then loading entities just using the list of keys.
I've used linq for years and it makes the basic and intermediate stuff way simpler, and the complex stuff no more complex. In hundreds of thousands of lines of code, we have exactly TWO queries where it ended up simpler to hand write SQL, and EF did not prevent us from doing that!
Hot takes: SQL is good. Great, in fact. Not just in what it's capable of doing, but in form . It has warts, yeah, but over the years I've been writing it I've realized most of them are there for a reason. To me it's more than useful, it's beautiful . It's the absolute last thing I want a replacement for.
How do we ever hope to differentiate between useful evangelism and stockholm syndrome? Either way, I'm probably learning a lot of postgresql this year. I do really wish we had at least settled on one data format instead of having enough differences between PL data and DB data to start building ORMs.
Reminds me of Microsoft's KQL https://learn.microsoft.com/en-us/azure/data-explorer/kusto/...
Earlier quoted context omitted.
The stiff syntax is a feature . The infamous 1000 line sales report query is already a bear to maintain. If you get a clever developer reordering syntax it will only be worse.
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.
The 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…
UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%'
from counters
filter startswith(name, 'prefix.')
derive {
new_value = value + 1
}
select {
name, new_value
}
update countersFor me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…
To me it seems quite nice, but really just trivially different from SQL - like if Ruby was 'friendlier syntax that transpiles to Python', meh? You'd use whichever you happened to learn first and not bother with the other. (That's often true even though it's more than that of course.) The examples arbitrarily make SQL look more verbose: SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 Yes! Of course I'd…
For me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…
I don't get that - to me the examples are much less readable than SQL and I don't understand why I should want to use this. Like, yes, you can reorder the query sections, which seems to be everyone's complaint about SQL, but then you also have multiple types of brackets, colons and other syntax for no reason, all while not really accomplishing anything SQL doesn't already do. What's the attraction?