[warwickschroeder]

A migration that builds or drops an index, changes a key, or alters a column on a large table can block writes for a long time during an upgrade. On the SQL Server and PostgreSQL persisters, nothing fails when someone adds a step like this or changes one in an existing migration. This adds the EF counterpart of #6013: an approval test per persister that lists those steps for each migration, so the change gets an upgrade guide entry before it ships.

What this adds

• A slow-step approval for each EF persister that lists index and key changes, new foreign keys and check constraints, altered columns, NOT NULL new columns and raw SQL, with no database server.
• Edits to the shared full-text SQL fail it, because raw SQL steps are listed word for word.
• The failure message comes before the diff and says to record a changed step in the upgrade guide, and to add a new migration rather than edit an old one.
• It ignores new tables, nullable new columns, renames and drops, and changes to the SQL that EF Core writes for a step.
• Docs in docs/testing.md.

Tests

• ServiceControl.Persistence.Tests.SqlServer and ServiceControl.Persistence.Tests.PostgreSql: the primary's slow migration steps are unchanged.
• ServiceControl.Audit.Persistence.Tests.SqlServer and ServiceControl.Audit.Persistence.Tests.PostgreSql: the audit full-text index SQL, the only slow step there, is unchanged.

[rbev]

This goes a little beyond the raven one doesn't it? It's freezing the entire schema, adding some minor friction for a developer to make any change rather than just an index-rebuild triggering change by adding an extra step after writing a migration.

Would it be better to trim the approval outputs to sql commands that are likely to trigger an index/table rebuild? CREATE/ALTER INDEX, SELECT INTO, etc

[warwickschroeder]

This goes a little beyond the raven one doesn't it? It's freezing the entire schema, adding some minor friction for a developer to make any change rather than just an index-rebuild triggering change by adding an extra step after writing a migration.

Would it be better to trim the approval outputs to sql commands that are likely to trigger an index/table rebuild? CREATE/ALTER INDEX, SELECT INTO, etc

@rbev The tests now check SQL commands that could cause slow migrations.