FluentMigrator.Opinions project ideas

[jzabroski]

I've been using FluentMigrator for over 3 years now, and have developed various best practices and thoughts around using FluentMigrator. While FluentMigrator 3.0 supports dependency injection, the next evolution of any injectable system is a good set of default values. Enter a new csproj/nuget package called FluentMigrator.Opinions (not yet created).

As an example of a good set of default values, consider a workflow where you develop thousands of database migrations. After awhile, the old migrations lose their meaning and it makes sense to "re-baseline" and "archive" old migrations. Some tools exist today to help support such workflows, but there is no unified, parsimonious architecture that allows such workflows to work flawlessly.

Here are some ideas:

1. Archiving Database Migrations.

   1. We have a folder structure where some C# code .cs files are not deleted, but archived. We literally copy the code into a folder called Archive/Migrations and use the .NET Core SDK project auto-globbing rules to not compile these items. They're still searchable via Control+Shift+F (Find In All Files, including External Items).
   2. If FluentMigrator customers add an IProvidesCallerFilePath interface to their Migration, we can automatically identify the path to .cs files needing archiving, and move them for the user. The IProvidesCallerFilePath is a convention whereby each migration would have a [CallerFilePath] on it via implementing a single interface string CallerFilePath {get; set;}. The FluentMigrator toolchain would then verify the implemented property has the [CallerFilePath] attribute.

2. Create the database if it doesn't already exist. This is very high complexity feature, due to all the idiosyncratic ways to create databases. Original target would be to support Postgres, SqlServer, and MySql variants.

3. Alternative ISyntax implementations.

   1. @fubar-coder has some ideas around this targeted for v4
   2. One use case discussed with @n1ghtmare is an alternative syntax for "implicit defaults" like the fact columns are NotNullable by default in FluentMigrator, whereas ANSI SQL default is nullable.

[jzabroski]

@Volodymyr I think this idea could be of interest to you.