Apply migration to every database in a shard using Elastic Database?

I have a project which uses the Elastic Database client library to work with a multi-tenant application. Each database belongs to a single tenant.

I would like to use FluentMigrator to manage the schema of every database in the shard.

Ideally, I’d like to configure a runner with multiple connection strings (which I get from the Elastic Database client).

    private static IServiceProvider CreateServices()
        {
            return new ServiceCollection()
                // Add common FluentMigrator services
                .AddFluentMigratorCore()
                .ConfigureRunner(rb => rb
                    // Add SQLite support to FluentMigrator
                    .AddSQLite()
                    // Set the connection string
                    .WithGlobalConnectionString("Data Source=test.db") // add multiple?
                    // Define the assembly containing the migrations
                    .ScanIn(typeof(AddLogTable).Assembly).For.Migrations())
                // Enable logging to console in the FluentMigrator way
                .AddLogging(lb => lb.AddFluentMigratorConsole())
                // Build the service provider
                .BuildServiceProvider(false);
        }

Is there a supported way to do this? Or do I need to explicitly create and execute one runner per database?

[fubar-coder]

You have two options:

1. Create services per-database
2. Provide your own IConnectionStringAccessor implementation and run the migrator multiple times where your IConnectionStringAccessor implementation returns a different connection string on each run (static variable?)

[jzabroski]

@c17r Thanks for the detailed use case layout. Very helpful.

WithGlobalConnectionString is per service provider. So, if you’re only referencing FluentMigrator objects within your DI scope, you can just create multiple service providers and dispose of them when you’re done. The “Global” is really per ServiceCollection at the point you call BuildServiceProvider();

It’s when you want to mix in outside objects not native to FluentMigrator that things get hairy, because then you’re mixing type universes and potentially lifetime scopes, and an “external” object you’re injecting might not exist at run-time because it’s been disposed.