Add/fix fields in CREATE MIGRATION

[tailhook]

1. message field is now reflected in schema::Migration
2. Added generated_by field to the migration
3. DDL-generated migrations are now marked with generated_by := MigrationGeneratedBy.DDLStatement.

[tailhook]

Also I've noted that you can't do SET message := in START MIGRATION:

edgedb> start migration to { module default { type X; }};
OK: START MIGRATION
edgedb[tx]> populate migration;
OK: POPULATE MIGRATION
edgedb[tx]> set message := 'from started';
error: EdgeQLSyntaxError: Unexpected 'message'
  ┌─ query:1:5
  │
1 │ set message := 'from started';
  │     ^^^^^^^ error

edgedb[tx:failed]> rollback;

This is a bug, right? But I'm not sure if it's fixable, as it conflicts with set {module|global|alias} syntax a bit.

[msullivan]

This is a bug, right? But I'm not sure if it's fixable, as it conflicts with set {module|global|alias} syntax a bit.

It's probably fixable, in this specific case of set message; probably not for arbitrary things?

[msullivan]

This is all fairly reasonable but I think that there is a simpler way that leverages our generic mechanisms for handling SET. Try to use that and follow up with me if it doesn't work?

[msullivan]

I think that if we populate the commands field here with kids[3].val.fields, the generic mechanisms for handling SET field := ... should pick up the commands and work without needing to have a message or generated_by field in qlast.CreateMigration, without needing to pick them out in the parser, and thus also without needing to handle them in _cmd_from_ast

[tailhook]

This is all fairly reasonable but I think that there is a simpler way that leverages our generic mechanisms for handling SET. Try to use that and follow up with me if it doesn't work?

It works. Thanks! Feels a bit too magical for someone not familiar enough with the codebase, though.

[tailhook]

Oh, by the way, I've just noticed that I've added uniqueness check into the quite generic check. Please double check that it's fine (looks like it's only used in two places, but I'm not sure). Maybe some SET field statements should be overridable?

[msullivan]

Oh, by the way, I've just noticed that I've added uniqueness check into the quite generic check. Please double check that it's fine (looks like it's only used in two places, but I'm not sure). Maybe some SET field statements should be overridable?

Yeah, that seems right.

[msullivan]

Oh I thought I approved this yesterday!