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

[ajcvickers]

See also #27723 for dry-run option.

[markm77]

This seems very useful for when the bundle is distributed to a third party who isn't so familiar with the source code. Features like info about available migrations and even perhaps the migration history sound great. I have an open source project, delivered via a Docker image, which uses EF Core for DB access. I want to help my customers manage migrations without them needing to access or understand the project source. It has been suggested to me to use something like Liquibase but I'm also keen to see what migration bundles can offer....

[markm77]

SQL preview sounds great too but I realise that's in another issue.... #27723 . Basically stuff that allows a customer to manage migrations as they wish (preview, test, rollback etc) without involving the source or me in the loop, e.g. to generate scripts, is very helpful.

[wdhenrik]

Please consider this an emphatic vote for validating how a bundle will change a target. I'm looking for something like:
bundle --connection [connection string] --script-pending --output [output path]

I'm using bundles in CI/CD and there doesn't seem any way for me to verify what changes will take place when run against a specific target. I'm generating a single bundle artifact in CI and want to use that all the way through the CD stack.

[matt-goldman]

Currently involved in a sev 1 production outage. We are screwed because we can't see what was deployed and what wasn't. Will be recommending against the use of migration bundles until this is added.