Comment by ben509 | Hacker News Reader

Comment by ben509 | Hacker News Reader

Parent Full thread

> In situations where EdgeDB cannot infer the type of an empty set [2]

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

> Strictly speaking, EdgeQL sets are multisets [1]

Like nulls, this is another broken aspects of SQL.

Maybe you can address these concerns, but I'm skeptical that it's relational:

* It conflates types with relation variables

* It's using links rather than foreign key constraints

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

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

* Constraints only seem to apply to scalars

The reason SQL has been successful is that tables are dead simple to understand, and you're throwing that out. This feels more like a graph database.

[1]: https://edgedb.com/docs/edgeql/overview#type-system [2]: https://edgedb.com/docs/edgeql/expressions/overview#set-cons...

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

Thanks for the clarifications!

Reply on news.ycombinator.com