Generate a rollback preview script

To generate full migration script, I can use the following:

dotnet fm migrate -p SqlServer2016 --no-connection -a Migrations.dll --preview -o="mgr.sql"

and it works fine.

But when I attempt to generate a rollback script the same way:

dotnet fm rollback all -p SqlServer2016 --no-connection -a Migrations.dll --preview -o="mgr.sql"

it spits out an error Unrecognized option '-p'

So, I looked at some examples and found out that I need to move the parameters to the back of the command line (somewhat unintuitive; I expected migrate down and rollback to be written together).

So tried with all to the end:

dotnet fm rollback -p SqlServer2016 --no-connection -a Migrations.dll --preview -o="mgr.sql" all

This time no error, but the generated script only drops VersionInfo table and doesn’t include Down from my migrations. Tried also by 5 and to 499 at the end - the same results. Tried also migrate ... down -t 499 and still got empty mgr.sql file.

Ideally, I would like to be able to generate a rollback script for all migrations that belong to specific version. In my project conventions (enforced with custom migration attribute) it means all migrations that start with given version number and include three last digits with ascending sequence numbers for individual migrations for the specific version of my website.

Of course, I would like to also be able to generate migrate SQL script the same way for the latest project version (which includes multiple migrations), but for now I’ve managed to extract the needed portion out of the full script using command line tools (sed, grep etc.)

[progmars]

Thank you for the advice.

For now, we deliver often enough, so, fortunately, our “patch batches” are not very large; usually about 20 - 50 SQL statements in 10-20 migration files in total.

I guess, we are abusing the fourth version field in our migration attribute. While in our CI, it is used more “by the books” - as an incremental build number and is never reset to 0 (so that might easily go past 3 digit limit indeed); however, in migrations we are resetting it to 0 every time when we increase any other version component. During development, every team member announces in our team chat that they are increasing the migration counter to reserve a slot for their migration file, and so it grows till its time to release a stable build for delivery.

I’m looking forward to the release 4.0. So far, experience with FluentMigrator has been great for me - it’s simple, reliable and straight-forward to use. No dependency on model state, SQL generation and custom naming conventions and behaviors were the main reasons why I chose FluentMigrator instead of Entity Framework code-first migrations.

[jzabroski]

Summary:

• Various Runners, including dotnet-fm need feature parity with each other. e.g., StartVersion
• Follow up with @progmars when cleaner approach in https://github.com/fluentmigrator/fluentmigrator/issues/1033 is implemented for rollback, rollback preview