
EdgeDB: A New Beginning - 1st1
https://edgedb.com/blog/edgedb-a-new-beginning/
======
quizotic
Well ... I kinda like the query syntax's ability to traverse relationships,
nest objects/sub-headings, and apply filters at the level of projected
expressions!

This has been done before of course, but I'm not sure I've seen this
combination of syntax on an RDB before. It's certainly easier to read and
write that a bunch of outer joins.

What would be nice to know is whether this can work on top of an existing PG
database, providing easier syntax.

While their last example makes _sense_:

    
    
      open_prs := User.<assignee[IS PullRequest] {  
          title
      } FILTER .status = 'Open'
    

I don't find it easy to read/understand. If the [bracketed expression] acts as
a filter, why not:

    
    
      open_prs := User.<assignee[IS PullRequest AND 
                                .status='open'].title
    

which preserves the nice dot-chaining for link traversal.

~~~
RedCrowbar
> What would be nice to know is whether this can work on top of an existing PG
> database, providing easier syntax.

That would require introspecting arbitrary relational schemas and trying to
represent them as an object graph. I don't think something like this can be
done automatically and reliably.

That said, we have a tentative plan to introduce support for external
databases (through FDWs, so not necessarily Postgres). The mapping
specification would have to be explicit though.

~~~
quizotic
Glad to hear about the FDWs ... but wouldn't foreign keys be your friend here?
What else would you need, really, to layer this on an existing DB?

~~~
RedCrowbar
If your schema consistently uses synthetic primary keys, maybe like the ones
produced by some active record ORMs, then, yes. Theoretically, we could make
an adapter that would make EdgeDB "understand" Django schemas, for example.

------
laszlokorte
I would love to see some auto generated (non-techie) graphical user interface
for this like phpmyadmin but w/o all the developer focused options.

Eg. if there is a m:n relationship do not make me enter some foreign key
values into a join table but give me some nice autocomplete fields or
checkboxes on either side of the relationships' types.

Or if there is some transitive relationship like "country -> city -> district
-> office", give me some nice way to filter the list of offices by a given
country oder district.

Auto generates this from the schema as web interface.

I already tried building this for SQL schemata but it seems like a schema
definition as provided by EdgeDB seems predestined for this use case.

~~~
zawerf
I recently tried Postgraphile [1] on an existing postgres database (briefly
just for fun, not in prod) and it sort of does what you want. As long as the
foreign keys are there, it will generate the correct graphql queries. It even
pluralizes the query names depending on whether it's a one-to-one or one-to-
many relationship. Once it's in graphql you can just use the interactive
graphql endpoint which has autocomplete and documentation to write your
queries.

A schema like:

    
    
      create table post (
        id serial primary key,
        author_id int non null references user(id),
        headline text,
        body text,
        ...
      );
    

Can query relations like so:

    
    
      allPosts {
        edges {
          node {
            headline
            body
            author: userByAuthorId {
              name
            }
          }
        }
      }
    
    

[1]
[https://github.com/graphile/postgraphile/tree/postgraphile#a...](https://github.com/graphile/postgraphile/tree/postgraphile#automatic-
relation-detection)

~~~
oneweekwonder
You aware of any graphsql layer for postgres implemented in pgsql or
pl/python?

Something like using JSONB datatype in a entity key value store table. Mapping
materialized views using pgsql json functions. To flatten out the data into
sql tables for normal consumption?

------
perfmode
I understand the desire to distance oneself from the term graph database, but
this is a graph database.

~~~
eigen-vector
I don't think their intent is to distance themselves from the term. Right
there in the post, they're mentioning that the object-relational universe
they're talking about is essentially a property graph. However, it doesn't
seem like it's built to mirror a traditional graph database.

~~~
andrioni
It seems more similar in spirit to triplestores, which are pretty neat all
things considered. It also reminds me a lot of Datomic, but without the
Clojure-ness and immutability.

------
1st1
redcrowbar (Elvis) and I (Yury) are the authors of the post. Happy to answer
questions ;)

~~~
andrioni
Is EdgeDB going to be Postgres fork, extension or a service that uses just
uses Postgres as a storage layer (like Datomic)?

~~~
1st1
It's closer to the storage layer: postgres is in the core and not directly
exposed (i.e. you won't be able to access it).

~~~
andrioni
Does it mean it will be possible to use EdgeDB with hosted Postgres databases,
like RDS and maybe Amazon Aurora (on Postgres mode)?

~~~
1st1
Maybe. This is something that we'll have to figure out later.

------
TickleSteve
"Databases have always been and will always be the defining piece of any
technological stack".

Sorry, I don't see this as true. Databases are no more "defining" of a tech
stack than any other part, comms, security, ui, business logic, etc.

You only see it as "defining" if the database is your product. In most cases,
the business logic is the defining part of the system, all parts of the tech
stack should be replaceable.

~~~
tuccinator
I would like to rebuttal. If there exists any dynamic application, you need
some type of data store to keep all of the records, whether it be a persistent
database or simply an in-memory database. So, in my opinion, this is a truthy
statement.

~~~
TickleSteve
If you're architecting your application around a particular mechanism, be that
a db or comms mechanism or whatever, then you're tightly coupled to it. This
is a mistake.

Most applications need to store data, but most applications dont _need_ to
store data in a particular db.

~~~
fusiongyro
Taking this attitude to your design is a great way to tank your performance
before you've even started. I have seen too many projects suffer from
overzealous architecture that treats the database as a persistence layer.
Designs that start out trying to abstract away the persistence layer wind up
building a complex caching layer.

~~~
TickleSteve
I agree, I'm not arguing for complete abstractions here, just showing that the
fact that you can abstract away the differences means that the db is not a
"defining" part of the system.

------
simplify
Does EdgeDB support variants[0]? I've always dreamed of a database that did.

[0] e.g.
[https://reasonml.github.io/docs/en/variant.html](https://reasonml.github.io/docs/en/variant.html)

~~~
RedCrowbar
In a way, yes. EdgeDB implements type inheritance and abstract types, so you
can have a schema like:

    
    
      abstract type Text:
        link body -> str
    
      type Post extending Text
      type Comment extending Text
      

And then query Text instances like this:

    
    
      SELECT Text {
        body,
        title := 'Post'    IF Text IS Post ELSE
                 'Comment' IF Text IS Comment ELSE
                 'unknown'
      };

------
senoroink
Definitely sounds cool in theory but where's the call to action? There's only
a form to sign up for an email update on the home page. Where is the source
code? How can I try this now?

~~~
1st1
Thanks for the interest! We'll release a technology preview (along with the
source code) in just a few weeks.

------
tuccinator
You must've done some benchmark tests, would it be possible to elaborate on a
plethora of different test speeds? Insertions per second, queries per second,
calculating sums, etc.

------
jazoom
I got an email about this this morning but I have no idea how I got on your
email list.

~~~
1st1
You or somebody else must have subscribed your email address. We've _never_
added any single email to our MailChimp list ourselves.

~~~
jazoom
If it was me it must have been a long time ago.

------
zzzcpan
"EdgeDB is based on PostgreSQL, and inherits all of its strengths:
reliability, ACID compliance, and performance."

So, basically PostgreSQL with a different query language. Can't figure out
what problem this is trying to solve.

------
jessep
On the home page it says, it is "relied upon in production by large
businesses". Which large business rely upon it?

~~~
1st1
We created a number of business applications that used earlier versions of
EdgeDB. The list of companies we worked with is on our magic.io page :)

------
slaymaker1907
So instead of having an ORM which I control, let’s bake it into the database
instead? This seems like a really bad idea.

~~~
1st1
EdgeDB is very far from being an "ORM in the database". It properly implements
an object data model on top of relational model, along with a properly
designed query language.

------
Arzh
This is undesirable

~~~
ovao
Your comment doesn’t have any substance. For what reason do you think it’s
undesirable?

~~~
Arzh
I see no need for another query language, I don't find using SQL to be that
taxing, and I don't find using different tools for different parts of the
stack to be a huge hurdle. This feels like it's made for people who have never
programmed before and will entice people to use it for that reason. Much like
MongoDB it will not work well at a scale of production and will need to be
replaced or scaled up to such an extent as to being too costly. Everything
about this in undesirable.

~~~
ziftface
I don't think people who have never programmed before are the only ones who
would be interested in more consistency and maintainability in their code.

~~~
Arzh
I don't see how letting something I don't control gives better
maintainability.

