← Back to context

Comment by 6gvONxR4sf7o

7 years ago

I always wished SQL had a better handle on sum types. If I have a user whose favorite story is an instance of Either[Movie, Book], then it's already a pain to deal with in a nice simple way. And that's as simple as sum types get.

7 comments

6gvONxR4sf7o

Reply
RedCrowbar  7 years ago

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

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

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

      1 reply →

jacques_chester  7 years ago

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

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

tlarkworthy  7 years ago

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