Interactivity

[vpetrovykh]

It's great to have those exercises at the end of each chapter. Most of them are small enough that they could be done "on paper" without actually having access to REPL.

They definitely present a good opportunity for making this book interactive. In addition to some instructions of how to try these in EdgeDB REPL locally we could have the online version of the book use the same mechanism we currently use in the "interactive tutorial" to provide an interactive way to do the exercises. Each exercise is short, easily fits on a single screen and we could have an extra button for showing the "official solution" with explanations. We already have the file with the schema & data needed for the exercises, so that can be used to populate the database.

The examples in the main body of the chapter should not be interactive, though, as messing up one of them would lead to issues down the line.

[Dhghomon]

@vpetrovykh I've been looking at how the tutorial works to get an idea for the Easy EdgeDB version, which will probably be about the 3rd major PR after the current one (before that will be one to move to 3.0 syntax and nice things like the splat operator, then one more to add a few chapters to make Easy EdgeDB 2.0). I've been experimenting a bit and looks like inserts can just be manually placed inside the generated .edgeql file after which the only complaint you get is to change the migration hash to the one it instructs you to use.

If that's so then I wonder if the whole thing could be done over two files with each chapter being its own module? Here's a simple version:

module chapter1 {
  type Person {
    property name -> str;
  }

}

module chapter2 {
  type Person {
    property name -> str;
    multi link places_visited -> Place;
  }

  type Place {
    name -> str;
  }
}

Then it generates the edgeql file and the inserts can be manually put in:

CREATE MIGRATION m17dyxizlcz3dlaiqvnfoj5fd4q7eux55jh7cpdhc2jkjnh4c6ijyq
    ONTO initial
{
  CREATE MODULE chapter1 IF NOT EXISTS;
  CREATE MODULE chapter2 IF NOT EXISTS;
  CREATE FUTURE nonrecursive_access_policies;
  CREATE TYPE chapter1::Person {
      CREATE PROPERTY name: std::str;
  };
  CREATE TYPE chapter2::Place {
      CREATE PROPERTY name: std::str;
  };
  CREATE TYPE chapter2::Person {
      CREATE MULTI LINK places_visited: chapter2::Place;
      CREATE PROPERTY name: std::str;
  };

  # Chapter 1 inserts
  insert chapter1::Person {
    name := "Jonathan Harker"
  };

  # Chapter 2 inserts
  insert chapter2::Place {
    name := "Munich"
  };
  insert chapter2::Person {
    name := "Jonathan Harker",
    places_visited := (select chapter2::Place)
  };
};

After that I'm not sure if there's a way to unknowingly insert a set module chapter1 command but even if the user has to do that manually it might not be bad as a small module exercise. Readers might find it fun to try setting the module to different chapters to peek ahead too.

And then if every chapter schema ends up in a single file then it could become the single source of truth and would make maintaining each separate chapter schema that much easier: just copy and paste from the main file that the interactive database uses. Do you think this approach could work?