I always wished SQL had a better handle on sum types. If I have a user whose fav...

RedCrowbar · on May 9, 2019

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

6gvONxR4sf7o · on May 9, 2019

Can you tell me whether I'm understanding this correctly?

Would this query result in, e.g. [(director: Null, author: J.K Rowling), (director: Spielberg, Null), ...] or would it be [author: J.K. Rowling, director: Spielberg, ...] or just plain strings: [J.K. Rowling, Spielberg, ...]? I still don't totally get the model here.

RedCrowbar · on May 9, 2019

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

6gvONxR4sf7o · on May 10, 2019

Thanks for the clarification! Seems really cool :)

jacques_chester · on May 9, 2019

This struck me just yesterday. You're left with using nulls (which is a sin punishable by poor data quality) or multiple tables for each sum type. Annoying.

garmaine · on May 10, 2019

Tables should be lightweight. It's the cruft the language and implementation that makes you avoid them.

tlarkworthy · on May 9, 2019

That is an acute observation and something I might consider dumping SQL for, or rather, I feel SQL could be upgraded to include