.Net Core - Change database migrations depending on environment

Question

So, I'm trying to figure out what the golden path is for running an application against a PostgreSQL database in development and a SQL Server database in production. The difficult part is that the migrations will be different. Currently, my approach is like this:

public void ConfigureServices(IServiceCollection services)
{
  services.AddDbContext<ApplicationDbContext>(SetDbContextOptionsForEnvironment, ServiceLifetime.Transient);
}

private void SetDbContextOptionsForEnvironment(DbContextOptionsBuilder options)
{
  if(_environmentName == "production") {
    options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]);
  }
  else {
    options.UseNpgsql(Configuration["Data:DefaultConnection:ConnectionString"]);
  }
}

Is the preferred way to keep the migrations in a separate assembly and specify that assembly in the options? So then I need to have multiple definitions of the same DbContext in those assemblies as well?

You can use preprocessor directives to control this. Create a new build for you in development, define a conditional compilation symbol for postgre devs and use preprocessor directives to switch between implementations... `#if POSTGREWTFDUDE /* pgre */ #else /* ss */ #endif` — , Aug 19 '16 at 20:12
I don't think pre processor directives help here. The environment is known. The question is how to maintain separate migration collections for two different target databases. — jaredcnance, Aug 19 '16 at 20:15
Okay I guess I'm not being clear. This is very specific to .Net core. The environment is know at runtime. We always know whether its production or not. The question is related to maintaining different sets of entity framework code first migrations.. — jaredcnance, Aug 19 '16 at 21:44
@user2322026: I deleted my answer since it seemed it wasn't anywhere close to useful to what you were asking and I didn't know enough of the specifics of what you're using to give a non-general answer. I apologize for misunderstanding what you meant! Thank you for your patience and reply! — Jesus is Lord, Sep 07 '16 at 05:59

score -3 · Accepted Answer · answered Nov 30 '16 at 22:39

-3

After thinking on this for quite a while, I believe that this is an anti-pattern. Regardless of my particular use case (postgres in dev, SQL Server in prod), I think it is frowned upon to use different database systems for different environments as there may be unexpected issues after deployment. Best to stick with the same one for development and production.

answered Nov 30 '16 at 22:39

jaredcnance

712
2
5
23

As an update I did end up implementing this for both PostgreSQL and MSSQL Server. But, I also included acceptance tests for both implementations. Rather than trying to maintain a single set of migrations that works for both providers, I split it into separate projects (MyApp.Migrations.SqlServer and MyApp.Migrations.PostgreSql) and run migrations for both. – jaredcnance Mar 30 '17 at 17:39

.Net Core - Change database migrations depending on environment

1 Answers1