I think this is awesome. This is like higher level and more readable + hopefully more efficient version of SQL.
BTW: In the nested-filters example, I don't understand how actor's `name` is being returned as `actor_name`. Where is `AS actor_name` being specified in EdgeDB's query?
It isn't. The quer returns an array `actors`, each of which has a property `name`. The SQL doesn't produce the same output, it's more like the SQL you'd write to solve the same problem.
Btw you can copy that example into the previous executable example input box and remove the reviews part to execute it.
Been using this for a toy project, and enjoying it so far!
Something I haven't quite figured out is, when using the TypeScript library, how to have more than two filters, ie x == z and y == a and b == c, without some pretty nasty nesting using the .op function.
That was my first reaction too. However, unlike the no-SQL monstrosities (like Mongo), this one seems to sit on top of a proper relational database, plus it seems to follow all the ol' good data modelling logic, just in a modern ish way, so I think it looks promising.
I'm not going to switch all my clients to it next week :) But it is definitely on my radar.
I think the parent comment meant the query libraries. The EdgeDB page lists "first-party clients for your favorite languages." They have clients for JS/TS, Go, Python, etc... but no Java/Kotlin yet.
This is one of the projects that I’m really excited about. The thing that concerns me are it’s performance characteristics with it being written in Python. Vs something like PostgREST which is written in Haskell and blazing fast. Is there more info about performance and scaling of Edge?
To be clear, the query compiler (that turns an EdgeDB query into a SQL query) is written in Python. And AFAIK, compiling the query should be very fast compared to actually executing it!
Learning projects for proof-of-concept can be written in Python, but not a production database. It seems that Rust has been working its way from the corners towards the core. For instance,the edgedb-cli is a rather elaborate rust project.
Hopefully, the adoption of Rust continues through the rest of the project. I love Python but it's not the right tool for the job.
30 comments
[ 3.4 ms ] story [ 90.3 ms ] threadBTW: In the nested-filters example, I don't understand how actor's `name` is being returned as `actor_name`. Where is `AS actor_name` being specified in EdgeDB's query?
Btw you can copy that example into the previous executable example input box and remove the reviews part to execute it.
This.
Something I haven't quite figured out is, when using the TypeScript library, how to have more than two filters, ie x == z and y == a and b == c, without some pretty nasty nesting using the .op function.
Here we go again.
I'm not going to switch all my clients to it next week :) But it is definitely on my radar.
Obligatory: https://www.youtube.com/watch?v=b2F-DItXtZs
EdgeDB looks fantastic.
Improved CPython performance in 3.11 (released) - https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-fas...
Improved parallelism in 3.12 and 3.13 - https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goa...
Improved memory efficiency in 3.12 - https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goa... - https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goa...
Hopefully, the adoption of Rust continues through the rest of the project. I love Python but it's not the right tool for the job.
Most likely you'll be surprised
[1] Show HN: EdgeDB 1.0 (145 comments):
https://news.ycombinator.com/item?id=30290225
[2] EdgeDB 2.0 (323 comments):
https://news.ycombinator.com/item?id=32267287
It's a pretty common problem for a developer to have: "this query looks like it should be fast, but actually it's slow. What's the DB doing?"
I thought I saw somewhere that EXPLAIN was coming in EdgeDB 3.0(?)
Complex stuff gets weird.