Possible Feature - Preview Migration

[dmeierotto]

I like the design of your simple migration framework, however we would need a Preview option that just dumps the sql that is about to be executed(see fluent migrations preview feature). Would you happen to be planning a feature like this?

When we deploy to production, DBAs must run the scripts manually(policy issue).

[canton7]

Agreed, a --dry-run flag or similar would be nice. I'm not sure that it could be made to print the SQL that would be executed though...

For example, the Migration base class has a Connection property, which migrations can use as they see fit. There's a convenience 'Execute' method which I could hook into to prevent SQL from being executed, sure, but there's nothing to stop the migration from executing things directly through the DbConnection (using Dapper, for example).

There's also the complexity that we still need to allow the database to be queried. We need to fetch the current version, for example. Migrations may also work by fetching data from the database, modifying it, then writing it back: in this case we need to allow it to read data, but not write it. However the migration may rely on being able to write back modified data then read that modified data, which is not something we can support.

The only ways I can think to actually enforce this would be to take that DbConnection property away (undesirable, as it's a breaking change and would prevent people from using things like Dapper), or implement my own DbConnection which proxies the actual one, but that brings its own complexity because we still need to allow the current version to be queried from the database, and allow the migration to read from the database, as above.

Sure, most of this probably doesn't apply to your use-case (maybe you only use Migration.Execute and never access the Connection property), but I can't think of a way to make it work for the general case.

One option for you might be to implement your own Migration base class (add a property which prevents it from executing SQL, and remove the protected Connection property), then subclass SimpleMigrator, add your flag to prevent SQL execution, and override CreateMigration to set the same flag on your Migration base class. You'll also need to override anything which updates the current version...

So, I don't think your exact requirements can be met for the general case. It shouldn't be too hard for you to customise things for your use-case however (with limitations, such as not giving migrations access to the Connection). If there are changes I can make to SimpleMigrator to help this (such as making it easier to prevent it from writing to the database), I'm happy to do that.

[canton7]

Another option would be to implement a --dry-run function which doesn't attempt to instantiate or run any of the migrations, and just prints out which ones would be run. However there's be a hook that's run for each migration which you could override, which lets you instantiate the migration, set a "Don't Execute" flag on it, then run it. You'd still need to create your own migration base class (to add this flag and remove Connection), but you wouldn't have to do as much work to prevent the SimpleMigrator from doing things like updating the current version in the database.