Earlier quoted context omitted.
Hey Yury, Cool stuff! How do you folks solve the large amount of joins that are the result of graph queries? Any worst-case-optimal multi-way-join secret sauce :D? Also, with DBs like Datomic competing in the same area, do you have an immutability/versioning story?
Thanks! The secret sauce is to pack nested shape queries into array_agg-ed SQL subquery. So we never select unnecessarily wide rows.
Show HN: EdgeDB 1.0
91–100 of 332 posts
Re: Show HN: EdgeDB 1.0
#92Earlier quoted context omitted.
(EdgeDB CTO here) In a classic relational model everything is a tuple containing scalar values. Graph-relational extends the relational data model in three ways: - every relation always has a global immutable key independent of data (explicit autoincrement keys aren't needed) - this enables us to add a "reference type", which is essentially a pointer to some other record (i.e. a foreign key) - attributes can be set-v…
So it's basically an ORM over Postgres (and only Postgres)?
EdgeDB has:
- Full schema model with indexing, constraints, defaults, computed properties, stored procedures
- A query language that replaces SQL. If there's something you can do in SQL that isn't possible in EdgeQL, it's a bug.
- The query language is backed by a full type system, grammar, set of functions and operators, etc.
- A set of drivers for different languages that implement our binary protocol.
By any definition, EdgeDB is a database. It's a new abstraction built on a lower-level abstraction: Postgres's query engine. Both abstractions indubitably fit any reasonable definition of "database".
Basically: just because there's a declarative object-oriented schema doesn't mean this "is just an ORM" (unless your definition is quite pedantic).
Re: Show HN: EdgeDB 1.0
#93How it is a new database? Or an advanced orm?
Re: Show HN: EdgeDB 1.0
#94(Tao uses mysql and stores graph data as pretty much key/value pairs, and then a layer on top to query it)
Re: Show HN: EdgeDB 1.0
#95Can someone from EdgeDB explain why the SQL isn't as simple as what I have below? What am I missing? Why is that cross join lateral necessary: SELECT title, ARRAY_SLICE(ARRAY_AGG(movie_actors.name WITHIN GROUP (order by movie_actors.credits_order asc)),0,5) avg(movie_reviews.score) FROM movie JOIN movie_actors on (movie.id = movie_actors.movie_id) JOIN person on (movie_Actors.person_id = person.id) JOIN movie_reviews…
Because that only gives you actor names, not records, and also because arrays aren't a universal SQL feature.
Re: Show HN: EdgeDB 1.0
#96I tried the beta around August last year. I struggled grokking it mostly because I had had very minimal experience with SQL - which it kind of assumed you already know the drawbacks of. However, I did like the idea very much. Looking forward to giving it another try soon!
Thank you! Working EdgeDB requires 0 SQL knowledge, you are not going to ever use it again. To quickly learn EdgeQL I recommend our online interactive in-browser tutorial: [1] We also have a book, it's called Easy EdgeDB, check it out here: [2] [1] https://www.edgedb.com/tutorial [2] https://www.edgedb.com/easy-edgedb
Re: Show HN: EdgeDB 1.0
#97Earlier quoted context omitted.
(EdgeDB CTO here) In a classic relational model everything is a tuple containing scalar values. Graph-relational extends the relational data model in three ways: - every relation always has a global immutable key independent of data (explicit autoincrement keys aren't needed) - this enables us to add a "reference type", which is essentially a pointer to some other record (i.e. a foreign key) - attributes can be set-v…
It's the first time I hear about graph-relational DBs. I remember back in college learning about graph databases, but since I never touched one I don't remember much TBH. Is a graph-relational database something completely disjointed from a graph database? Or do they share some performance improvements to some use cases? Also does EdgeDB keep the advantages of a true graph database even being based on Postgres?
This is unsurprising, because we just invented the term :-)
> Is a graph-relational database something completely disjointed from a graph database?
Graph-relational is still relational, i.e. it's a relational model with extensions that make modeling and querying graph-like data easier. And in apps everything is graph-like (hence GraphQL etc). An important point is that graph-relational, like relational is storage-agnostic, i.e. it makes no assumptions on how data is actually arranged on disk.
Pure graph databases, on the other hand, encode the assumption that data is actually _physically_ organized as a graph into their model and query languages.
I guess the word "graph" is simply too overloaded in computing.
Re: Show HN: EdgeDB 1.0
#98Earlier quoted context omitted.
So it's basically an ORM over Postgres (and only Postgres)?
We're working on a more comprehensive explanation of why EdgeDB isn't an ORM. Does EdgeDB do "object-relational mapping" under the hood — absolutely. The reason we try to distance ourselves from the category of ORMs is that the term "ORM" comes with a big bag of preconceptions that don't apply here. EdgeDB has: - Full schema model with indexing, constraints, defaults, computed properties, stored procedures - A query…
If I build a DB Schema in EdgeDB, can I interact with the underlying Postgres instance using regular SQL?
Re: Show HN: EdgeDB 1.0
#99Eg. vs Cypher or the likely-Cypher-compatible forthcoming GQL standard? https://www.gqlstandards.org/