Migrations: Multiple providers

[rowanmiller]

In EF7 we're going all in with provider specific migrations, so if I target SQL Server and PostreSql then I need to gen two sets of migrations. Our migrations commands aren't setup to deal with two (or more) sets of migrations though.

We probably need a first class concept of a provider (also needed for reverse engineer) and then we can have migrations identify which provider they are for (possibly in the attribute we use to identity which context they are for).

[rowanmiller]

We should atleast implement enough that we don't have breaking changes later

[bricelam]

Parts of this depend on #1904

[bricelam]

Notes from today's design meeting:

• We can have one model differ that diffs "all" annotations
  • Annotations can be filtered by provider prefix for all participating providers
• Some core/relational metadata should be overridable per provider (e.g. StoreType & DefaultExpression)
• Some core/relational metadata doesn't need to be overridable (e.g. DefaultValue)
• Post-RTM, providers can optionally scaffold their annotations as extension methods:

// RTM
migration.AddColumn("Id", "Person", "int")
    .Annotation("SqlServer:GenerationStrategy", "Identity");

// Post-RTM
migration.AddColumn("Id", "Person", "int")
    .ForSqlServer(generationStrategy: SqlServerValueGenerationStrategy.Identity);

[bricelam]

I chatted with @rowanmiller today, and we decided to do the following for RTM.

We'll scaffold migrations that are specific to the active provider. For example, given the following model...

modelBuilder.Entity<Person>()
    .SqlServerTable("People")
    .SqliteTable("people");

...the following migration would be generated if SQL Server was the active provider at design-time.

migrationBuilder.CreateTable(
    name: "People"
    /* ... */);

However, to unblock people from hand-crafting migrations that can run against multiple providers, we'll implement #2258. With that, you could write a migration that looks something like this:

migrationBuilder.CreateTable(
    name: activeProvider == "EntityFramework.SqlServer"
        ? "People"
        : "people"
    /* ... */);

[rowanmiller]

...and once we have everything working we can look at scaffolding something like the conditional code in the final snippet when there are multiple providers registered... but that will presumably be post 7.0.0.

Also worth noting that by having the current provider accessible to the migration code we are already better than EF6, so we easily clear the "EF6 parity" bar.

[bricelam]

The investigation work here is done; I have enough context to avoid breaking changes in the future. We can move this issue to the backlog now.

[rowanmiller]

We already have the flag to allow you to do different things based on the active provider. We think this is enough and we don't need to scaffold for multiple providers.