Migrations Bundles: Provide more info about the bundle

[bricelam]

Today the bundle is effectively just dotnet ef database update, but I've been thinking it would be helpful to include gestures for these commands too in the bundle:

• dotnet ef dbcontext info (or even just a way to see the DbContext type of the bundle in --help)
• dotnet ef migrations list
• dotnet ef migrations script (although this seems much less important since you can just generate a script instead of a bundle in the first place)

[sturlath]

@bricelam will this be included or dropped for next version? I really can´t see how useful this is if we can´t see what´s "in the box".

Imagine running this in a release pipeline with gated approvals? You need to know what is being run.

But if not included could the following be a middle step?
Running dotnet ef migrations script in the build pipeline (at the same time we create the bundle exe) create an accurate representation of what the bundle does?

If it does then maybe I would create both and have the approval be on the script but when accepted I will run the exe.

[bricelam]

Yes, creating a script (especially with --idempotent) at the same time is an accurate representation of the bundle.

[sturlath]

I´m still getting my head around bundles and what they solve so hope you can help me clarify something.

There are problems with script as you point out here so will the bundles solve them and why?

When you said bundles were "accurate representation" of scripts, my question is then if the bundle do/don't do more than just run the same thing?

Are bundles just a self contained package (exe) that are just easy to work with?
Something like

"Just provide a connection string and we will connect to the database for you and apply the idempotent scripts contained within me"

Then if you already have a build pipeline in azure that creates scripts and runs them, with something like Azure SQL Database deployment task, then that's the same as bundles?

Sorry if this question is too basic but there is not much to go on since this is all so new...

[bricelam]

We solved the issues I listed there in EF Core 5.0 which made the script a lot more robust.

The problems that still exist with the script which are solved by bundles are:

• They need something (usually database-specific) to execute them (Sqlcmd, SSMS, MSDeploy, etc.)
• Most tools that execute SQL Server scripts simply continue on to the next statment when they encounter an error. This can leave the database in a very bad state
• Transaction handling isn't always obvious. For example, MSDeploy appears to completely ignore the BEGIN and END statements and tries to wrap everything into a single transaction

If you have a working solution, there's no need to move to bundles. Bundles simply enable more databases to achieve the same rich experience on more platforms.

[sturlath]

Will it be possible to do something like this?

dotnet ef migrations bundle script secondMigration FirstMigration -o ./rollback_script.sql