Order of statements using Execute.WithConnection() and Execute.Sql()

Describe the question I’m trying to use .patch files to migrate my MSSQL stored procedures instead of describing the full stored procedure for UP and DOWN migrations. (Side note: because I’m simultaneously dealing with many code branches and using the traditional approach I found that after merging branches, some stored proc migrations might undo older changes. And patch files can be applied in reverse too, which simplifies the DOWN migration).

Anyway, to do this I have to extract the current script from MSSQL (via sp_helptext)

So, in short, I have this migration:

public override void Up()
{
    string newScript = "";
    Execute.WithConnection((connection, tx) => newScript = GetStoredProcTextAndApplyPatch());

    if (string.IsNullOrWhiteSpace(newScript))
        Console.WriteLine("No script to execute");
    else
    {
        Console.WriteLine("Executing change script");
        Execute.Sql(newScript);
    }
}

When migrating (using console runner), it seems the bottom block executes first, hence newScript is empty and the Execute.WithConnection executes after that. Some kind of delayed lambda function?

I guess I can execute the new script inside the .WithConnection block, but then I don’t have access to the fluent features.

Is this behaviour intended?

Documentation Pages You’ve Read So Far I browsed through the documentation and open issues on Github

Expected benefit Statements to be executed in order in which they appear in the code.

Information (please complete the following information):

• OS: Windows 10
• Platform: .NET 4.7.2
• FluentMigrator version [ e.g 3.2.9 ]
• FluentMigrator runner [FluentMigrator.Console 3.2.9]
• Database Management System [ SQLServer ]
• Database Management System Version [ SQLServer 2016 ]

Additional context

[jzabroski]

I suppose if we implemented #854 , we could have each top-level command return a Task, and have a way to ContinueWith the migration. Perhaps then a With.Task or something could be used to get any results from Execute.WithConnection. This would be more possible with return type covariance mentioned for C# 9.0 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/

However, it would also mean dropping support for legacy .NET Framework, etc. So it’s realistically not going to be a change I’ll want to make for at least two years.

[jzabroski]

BTW, this may seem dumb, but - rather than use patches, why not just dump a copy of the entire object tree into a folder structure where the parent folder is a release name. Then your migration simply computes a sha1 hash sum on the most recent release name and the previous release number, and does a file comparison for differences. Then you avoid the complexity of figuring out how a patch got applied, and potentially any bugs with a patch not working since you’re doing a live merge operation in a production app (which is why I think your approach is interesting).

You could then create githooks that block modifications to a release folder once its created. You can also create a post checkout hook that makes a folder readonly.