RedCrowbar

Correct.

>> Why not bottom, or are containers not covariant? I'm worried that we're not clear about the difference between variables and values.

Yes, `{}` is inferred as `anytype`, but we chose to restrict its use in output for interoperability reasons: the output of a query must be of a concrete, known type.

>> Strictly speaking, EdgeQL sets are multisets [1] > Like nulls, this is another broken aspects of SQL.

From the purity standpoint, yes, but in practice, duplicate values are either expected, or too expensive to eliminate. That said there is a `DISTINCT` [1] aggregate.

> * It conflates types with relation variables

Not exactly. We do use the same symbol to denote a type, and a relation that it represents, but the context of which is which is always clear (i.e. Foo in a cast expression is always a type), but Foo in a regular expression is always a relvar.

> * It's using links rather than foreign key constraints

Links are an abstraction over a foreign key. In the vast majority of cases foreign keys are implemented as 'some_id' -> 'id' anyway. If you want a custom foreign key, you can set an expression constraint on a property or a link.

> * It doesn't seem like the user can even specify a candidate key

type Foo { constraint exclusive on ((.name, .last_name)) }

> * Which is why the "id" field is magical and special

See RM proscription 15 in the Third Manifesto [2]

> * Constraints only seem to apply to scalars

They aren't, see above.

[1] https://edgedb.com/docs/edgeql/funcops/set#operator::DISTINC... [2] https://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf

If fetched as JSON: {"favories": [{"director": null, "author": "J.K Rowling"}, {"director": "Spielberg", "author": null}, ...]}

You can also query the actual object type by referring to the __type__ link:

  SELECT User {
    favorites: {
        __type__,
        [IS Movie].director,
        [IS Book].author,
    }
  };

EdgeDB is built on Postgres, it's not from scratch.

In EdgeQL, expressions are element-wise functions over the cross-product of the input sets:

    edgedb> SELECT {'First', 'Second'} ++ '!';
    {'First!', 'Second!'}

EdgeQL queries are essentially set comprehensions.

`(a, b)` is a cross-product, just like "SELECT * FROM a, b"

You can do that in EdgeDB:

  type Movie { 
    property director -> str
  };
  type Book {
    property author -> str
  };

  type User {
      multi link favorites -> Movie | Book
  };

  SELECT User {
    favorites: {
        [IS Movie].director,
        [IS Book].author,
    }
  };

There are good examples in the tutorial: https://edgedb.com/docs/tutorial/queries#ref-tutorial-querie...

The last query is still returning a flat set of Movie objects. The shape selector describes _related_ data that is also needed to be fetched by the query. So, the query actually returns multiple sets that can be reconstructed by the client into a graph of objects (or serialized into JSON).

Yes, and that's actually the point being made in the post. You need to rewrite your queries to make SQL happy.

There is a difference. You are right in a sense that scalar expressions are a form of a table expression, but...

This is a valid expression:

  SELECT (SELECT count(*) FROM table) + 1

This is not:

  SELECT (SELECT * FROM table), 1

In EdgeQL:

  SELECT (count(SomeType) + 1)

and

  SELECT (SomeType, 1)

are equally valid.

Yes. EdgeDB actually used to have it earlier on, but we felt that the design wasn't good enough, so we dropped the FTS support for now. The idea is to have a datamodel/QL UI such that we are not just copying the Postgres FTS design, so things like a different search index backend (e.g. Elastic) are possible.

> btw, do you implement any edgeql-specific optimizations?

Not on the planner level. Most of EdgeQL-specific low-level stuff is currently built as an extension with helpers. Our strategy is to upstream as much as possible, including any possible improvements to the planner that benefit EdgeDB.

Similar in spirit to Django and SQLAlchemy Core SQL expressions.

The reference page has some details [1]. Our goal is to match and exceed the experience of managing the migrations with a high-level ORM like Django. This is one of the reasons behind the SDL/DDL duality. EdgeDB has to grow some tooling around it before we get to that point, though.

[1] https://edgedb.com/docs/edgeql/ddl/migrations

Yes, one of the main goals of EdgeDB is to provide improved ergonomics and productivity through a modernized data model and query language. And do that without a significant performance cost.

Lower performance in benchmarks is explained by an I/O bottleneck in the EdgeDB server, the queries are not less efficient. There will be performance improvements in subsequent releases.

You got it! We designed EdgeQL from the first principles of the relational algebra and the set theory, with focus on practicality. There are a lot of similar ideas in Tutorial D, but EdgeQL is not a descendant of it.

We are working on a similar query builder syntax for edgedb-python.

Have you tried pg_upgrade?

I don't think it's fair to call UP Express a failure yet. It certainly had a bumpy start, but the ridership seems to have been improving recently [1]

[1] https://www.citylab.com/transportation/2018/01/how-toronto-t...

> The latter can he mitigated by using "ordered UUIDs": you can generate UUID1 (nominally time-based) such that the final value has a sequential "head" and a random "tail"

Specifically, in PostgreSQL such UUIDs can be generated using uuid_generate_v1mc()

> materialized views

Yes, although not in the initial release. EdgeDB _does_ support regular views, which, like the queries, can define arbitrary data hierarchies which can be treated like real object types. This topic deserves a separate blog post.

> built-in versioning

Not planned as a native feature as of now, although that's something that can be implemented on top with the query rewrite system.

> story on how to play it nice with backend languages

Immediately, EdgeDB supports a RESTful protocol with JSON as the exchange format. We will be adding native protocol implementations for major languages as well.

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.

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

The [bracketed expression] is a target object type specifier in a path expression and can appear at any point in the path:

  User.<assignee[IS PullRequest].assignees[IS User].name

The reason for the FILTER clause is that you may want to write something like:

  FILTER User.name = 'Alice' OR User.<assignee[IS PullRequest].status = 'Open'

which is impossible to express if we were to simply filter each node set in the path separately.

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'
  };

Matisse is close to a traditional ODBMS which implements .NET class mapping to SQL. EdgeDB is not an ODBMS in that sense, it is not tied to any platform or class model.

The main differentiating point of EdgeDB is EdgeQL (and native GraphQL support).

I have to disagree with this assessment. The change was to publish the Weekly content as standalone articles throughout the week rather than wait for the Weekly Edition. The Weekly Editions are still there if you prefer to read LWN once a week. I don't think the quality of the content has suffered as a result.

PEP 394 is not set in stone. There have been occasional discussions on amending it, e.g [1]

[1] https://mail.python.org/pipermail/linux-sig/2017-July/000029...

cat /proc/cpuinfo | grep pti

I'm not the gp, but at least in downtown Toronto there are several providers offering uncapped fiber connections at reasonable prices:

https://www.beanfield.com/residential/ https://www.coextro.com/