Migrations script: wrap queries in `sp_executesql` when using `--idempotent`

What problem are you trying to solve?

When generating migration scripts with dotnet ef migrations script --idempotent, the tool generates invalid SQL in some cases. Consider the following migration:

public partial class CreateAView : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.Sql("create view MyView as select 1;");

This results in the following migration script:

IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20220301060232_CreateAView')
BEGIN

create view MyView as select 1;

END;
GO

This script is invalid because create view must be the only statement in an SQL query batch; it cannot appear inside IF.

Describe the solution you’d like

The easiest solution seems to me to wrap custom SQL inside sp_executesql. Something like this:

IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20220301060232_CreateAView')
BEGIN

DECLARE @query nvarchar(max) = N'
  create view MyView as select 1;
';
EXECUTE sp_executesql @query;

END;
GO

This works for Microsoft SQL server – I’m sure other dialects have their own equivalent of dynamic SQL.

[Sjlver]

@roji That all makes sense.

I’m just wondering why we would want to put the burden on the user (and write docs, and answer the occasional question if users don’t find the docs, etc.). Is the increase in complexity of the raw SQL feature really so large as to outweigh the benefits for the users? It might well be; I don’t know how the feature is implemented… but my hunch is that it would probably be less than 30 LOC to add a call to sp_executesql. Plus a unit test. Plus optionally another few lines and a regular expression to only wrap those SQL statements that need it.

Anyway, at this point I feel like I’ve been vocal enough 😉 Let me just use this opportunity to express my gratitude to EF. It’s a great software, and I shudder when I think of previous projects that used stored procedures instead of an ORM… so: thank you!

[Sjlver]

@ajcvickers Yes, that’s absolutely right.

I would prefer to not do this for two reasons:

• It makes the migration more complicated. For example, I’d have to escape certain characters in the raw SQL when putting it inside a string literal.
• It’s unnecessary in most cases. When using dotnet ef database update, the migration works just fine. It even works just fine when used with dotnet ef migrations script. Only when adding the --idempotent switch does the problem occur.

The latter point makes me think that the problem is really with --idempotent, and not with the raw SQL.