Live data from Hacker News

Show HN: EdgeDB 1.0

edgedb.com

91–100 of 332 posts

Re: Show HN: EdgeDB 1.0

#91
post #7
post #6

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.

Sounds like this is not dissimilar from the GraphQL-to-SQL compiler in Hasura, which also brings out surprising performance for wildly nested frontend queries.

Re: Show HN: EdgeDB 1.0

#92

Earlier 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)?

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 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

#94
I only glanced through this, but would you say there’s some vague similarities (ignoring the distributed/caching aspects) to Facebook’s TAO here? For example, as a user of this, would I have to care about the Postgres schema, or is that abstracted away from me?

(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

#95
post #62

Can 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.

You can JSON_AGG to get whole records.

Re: Show HN: EdgeDB 1.0

#96
post #34

I 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

I suspect it was not specifically SQL knowledge they were lacking, but knowledge of how to work with relational databases.

Re: Show HN: EdgeDB 1.0

#97
post #85

Earlier 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?

> It's the first time I hear about graph-relational DBs.

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

#98

Earlier 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…

How exactly is EdgeDB run? Is it a separate process from Postgres, or some kind of plugin? Can I run it over an existing Postgres instance?

If I build a DB Schema in EdgeDB, can I interact with the underlying Postgres instance using regular SQL?

Post reply on HN