Feature/idempotent migrations

[kamil-mrzyglod]

There is one thing which FluentMigrator lacks in my opinion - idempotent migrations(or rather idempotent generated SQL output). This is the only thing which prevents me from using it on production environment in my work(we have to prepare SQL scripts for DBA team because we haven't been given permission to perform automatic migrations yet).

Because it would be easier to use original package than the one from our private NuGet gallery, I would like to ask whether it would be possible to introduce those change into FM :)

[kamil-mrzyglod]

Ok, I see that not using Quoter breaks some tests, will come back with a fix in a day :)

[DustinVenegas]

Two things stand out to me in this change. First, database changes that are migrated shouldn't require idempotent checks since they, by definition, will be migrated. That said, it appears useful.

I'm not a core maintainer, but I believe a fluent expression syntax for Preconditions might be useful here instead. That chaining methodology might be less invasive and more flexible in the long-run since it would be easy to extend to arbitrary preconditions. Something to the effect of:

Create.Table("foo")
    .WithPrecondition(Preconditions.MustNotExist)
    .WithIdColumn();

Alter.Table("bar")
    .AddColumn("someCol")
    .Precondition(Preconditions.MustNotExist);

Delete.Table("foo")
    .WithPrecondition(Preconditions.MustExist);

[fubar-coder]

This is a huge change that's in its current implementation SQL Server specific and too intrusive. The time until the upcoming 2.0.0 release is too short to include/rework this implementation.

A rework that's based off 2.0.0 would be fine and I'd suggest a DB agnostic framework that allows the creation of "SQL script wrappers" that is able to make the SQL scripts idempotent.

I also saw that you introduced migration dependencies and it seems that they are only required to guard a migration from being run when a version in a version table is missing. There is some work underway to make the migration pluggable and the VersionInfo table might not exist at all, because the versions are stored differently, and the current implementation is SQL Server specific too.

My suggestion is, that the new version of this PR should only contain the "SQL script wrappers", but not the migration version guard, as this might be a candidate for a different PR.