How to know the migration is completed?

[hengwayong]

Describe the question
How to know the migration is completed?
Any way we can keep track the progress of migrator while it running

Documentation Pages You've Read So Far(https://fluentmigrator.github.io/api/v3.x/FluentMigrator.Runner.TrackingMigrationScope.html)

Expected benefit
There is a event or action call back when exception, error or the migrator complete

Information (please complete the following information):

• OS: Window 10
• Platform: .NET Framework 4.8
• FluentMigrator version: 3.3.0
• FluentMigrator runner: FluentMigrator.MSBuild
• Database Management System: Mysql
• Database Management System Version: Mysql 8.0

[fubar-coder]

You can create a "maintenance migration" (with the MaintenanceAttribute instead of the MigrationAttribute) and set the migration stage to MigrationStage.AfterAll.

This migration stage will now be called after each successfully applied migration. You can use the IVersionLoader service to get the latest version using the VersionInfo property. You have to query the database manually to get the latest version. You can now use some kind of communication mechanism to report the applied version.

EDIT: You cannot use IVersionLoader, because the version loader is scoped, while the maintenance instantiation is a singleton.

[jzabroski]

I don't understand the question. The migration is complete when the code returns. That is the callback mechanism.

Are you asking in the case where you use the dotnet-fm CLI tool? If so, as Mark suggested, you can write some kind of paging mechanism in an MaintenanceMigration w/ MigrationStage.AfterAll - like, email notification, etc. But you wouldn't be able to write the transcript from there.

I normally use Octopus Deploy to manage logging my transcripts and notifying of completed or failed deploys. We've been using it for over 5 years now. Works great.

[hengwayong]

@fubar-coder @jzabroski Thank you for the feedback. I am not using the migrator in CLI but in-process, after read the documentation, so far do not found the call back mechanism you mentioned. Possible to share me the direction of call back mechanism?

Below is the code that I'm using to run the migrator

public void Migrate()
        {
            var serviceProvider = CreateServices();
            if (serviceProvider == null)
            {
                OnException("Create service fail");
            }
            else
            {
                using (var scope = serviceProvider.CreateScope())
                {
                    UpdateDatabase(scope.ServiceProvider);
                }
            }
        }
        #endregion


        private IServiceProvider CreateServices()
        {
            IServiceProvider serviceCollection = null;
            FluentMigratorLoggerOptions options = new FluentMigratorLoggerOptions();
            options.ShowElapsedTime = true;
            CustomLoggerProvider loggerProvider = new CustomLoggerProvider(new OptionsWrapper<FluentMigratorLoggerOptions>(options));
            CustomRunnerLogger logger = loggerProvider.GetLogger();
            logger.CompleteHandler += OnCompleteHandler;
            logger.ProgressHandler += OnProgressHandler;
            try
            {
                serviceCollection = new ServiceCollection()
                .AddFluentMigratorCore()
                .ConfigureRunner(_rb => _rb
                    .AddMySql5()
                    .WithGlobalConnectionString(connectionConfig)
                    .ScanIn(Assembly.GetExecutingAssembly()).For.Migrations())
                .AddLogging(_lb => _lb.AddProvider(loggerProvider))
                .BuildServiceProvider(false);
                return serviceCollection;
            }
            catch (Exception exception)
            {
                OnException(exception.Message);
                return null;
            }

        }

        private void OnCompleteHandler(object _sender, ServiceEventArgs _e)
        {
            OnComplete();
        }

        private void OnProgressHandler(object _sender, ServiceEventArgs _e)
        {
            OnProgress(_e.Message);
        }

        /// <summary>
        /// Update the database
        /// </summary>
        private void UpdateDatabase(IServiceProvider _serviceProvider)
        {
            var runner = _serviceProvider.GetRequiredService<IMigrationRunner>();
            if (runner.HasMigrationsToApplyUp() == true)
            {
                try
                {
                    runner.MigrateUp();
                }
                catch (Exception exception)
                {
                    OnException(exception.Message);
                }
            }
            else 
            {
                OnComplete();
            }
        }

The work around I did currently is, I created CustomLoggerProvider and CustomRunnerLogger which inherit and implement from ILoggerProvider and FluentMigratorRunnerLogger. And I do some override in CustomRunnerLogger, so I can hijet the message pass to WriteSay function, and return back to application as log. To detect the complition of migration I did some dirty solution by detect "migrated" in the message.

[jzabroski]

Maintenance migration looks like this:

using FluentMigrator;

namespace Your.Company.Your.Project.Database.DatabaseName.Maintenance
{
    [Tags(TagNames.UnitTest)]
    [Maintenance(MigrationStage.AfterAll, TransactionBehavior.None)]
    public class UnitTestAfterAll : Migration 
    {
        public override void Up()
        {
            // Execute Up callback here
        }
        public override void Down()
        {
            // Execute Down callback here
        }
    }
}

It is not a typical "callback", but if all you need to do is send a notification without any context, this should work. If you are using a custom in-process runner, you can inject services across your stack to add more details per migration. Like you mentioned, injecting your own logger is one way. Then, in this final maintenance migration, you can aggregate all log messages and sink them to whatever destination you want, e.g. email report. I would be careful with transaction semantics if you're aggregating a lot of log messages, as you may run out of string pool memory, e.g. due to internal string pool fragmentation.

The one limitation right now is maintenance migrations in a particular stage are not composable via a "choice operator" - there is no way to declare two maintenance migrations in one particular stage and choose which one runs first.

[hengwayong]

I see, thank you for your great advice, really appriciate