In the first part of this short blog post series we looked at how to change the database schema of a DbContext, now it is all about changing the schema of the EF Core Migrations at runtime.

The samples are on Github: PawelGerr/EntityFrameworkCore-Demos

Given is a DemoDbContext implementing our interface IDbContextSchema from the first part of this series.

public interface IDbContextSchema
{
  string Schema { get; }
}

public class DemoDbContext : DbContext, IDbContextSchema
{
 public string Schema { get; }

 public DbSet<Product> Products { get; set; }

 ...
}

At first we create a migration the usual way: dotnet ef migrations add Initial_Migration

And we get the following:

public partial class Initial_Migration : Migration
{
  protected override void Up(MigrationBuilder migrationBuilder)
  {
    migrationBuilder.CreateTable("Products",
                        table => new { Id = table.Column<Guid>() },
                        constraints: table => table.PrimaryKey("PK_Products", x => x.Id));
  }

  protected override void Down(MigrationBuilder migrationBuilder)
  {
    migrationBuilder.DropTable("Products");
  }
}

Next, we add a constructor to provide the migration with IDbContextSchema and pass the schema to CreateTable and DropTable.

public partial class Initial_Migration : Migration
{
  private readonly IDbContextSchema _schema;

  public Initial_Migration(IDbContextSchema schema)
  {
    _schema = schema ?? throw new ArgumentNullException(nameof(schema));
  }

  protected override void Up(MigrationBuilder migrationBuilder)
  {
    migrationBuilder.CreateTable("Products",
                        table => new { Id = table.Column<Guid>() },
                        constraints: table => table.PrimaryKey("PK_Products", x => x.Id),
                        schema: _schema.Schema);
  }

  protected override void Down(MigrationBuilder migrationBuilder)
  {
    migrationBuilder.DropTable("Products", _schema.Schema);
  }
}

If we try to run the migration then we get a MissingMethodException: No parameterless constructor defined for this object. because EF Core needs a parameterless constructor to be able to create an instance of the migration. Luckily, we can adjust the part that is responsible for the creation of new instances. For that we derive from MigrationsAssembly and override the method CreateMigration. In CreateMigration we check if the migration requires an instance of IDbContextSchema and whether the current DbContext is implementing this interface. If so, then we create new instance of the migration by ourselves and return this instance to the caller, otherwise we pass the call to the default implementation.

public class DbSchemaAwareMigrationAssembly : MigrationsAssembly
{
  private readonly DbContext _context;

  public DbSchemaAwareMigrationAssembly(ICurrentDbContext currentContext, 
        IDbContextOptions options, IMigrationsIdGenerator idGenerator, 
        IDiagnosticsLogger<DbLoggerCategory.Migrations> logger)
    : base(currentContext, options, idGenerator, logger)
  {
    _context = currentContext.Context;
  }

  public override Migration CreateMigration(TypeInfo migrationClass, 
        string activeProvider)
  {
    if (activeProvider == null)
      throw new ArgumentNullException(nameof(activeProvider));

    var hasCtorWithSchema = migrationClass
            .GetConstructor(new[] { typeof(IDbContextSchema) }) != null;

    if (hasCtorWithSchema && _context is IDbContextSchema schema)
    {
      var instance = (Migration)Activator.CreateInstance(migrationClass.AsType(), schema);
      instance.ActiveProvider = activeProvider;
      return instance;
    }

    return base.CreateMigration(migrationClass, activeProvider);
  }
}

The last step is to register the DbSchemaAwareMigrationAssembly with the dependency injection of EF Core.

Remarks: to change the schema (or the table name) of the migration history table you have to use the method MigrationsHistoryTable

var optionsBuilder = new DbContextOptionsBuilder<DemoDbContext>()
              .UseSqlServer("..."
                      // optional
                      //, b => b.MigrationsHistoryTable("__EFMigrationsHistory", schema)
                            )
              .ReplaceService<IModelCacheKeyFactory, DbSchemaAwareModelCacheKeyFactory>()
              .ReplaceService<IMigrationsAssembly, DbSchemaAwareMigrationAssembly>();

That's all!

Related Articles

entity framework core
Do Not Waste Performance by Not Using Temp Tables With Entity Framework Core
It has been a while since I released my article about the usage of temp tables in Entity Framework (v6). Meanwhile, Microsoft has released a completely rewritten version of its O/R mapper so my old approach is no longer applicable. But before we learn about a new one, let us…
Pawel Gerr
entity framework core
Better Entity Framework Core Performance by Reading Execution Plans
Both a LINQ query and an SQL statement are descriptions that state which data should be fetched, but not how.. Sure, when reading LINQ or SQL, we can make assumptions about the performance but not in every case. Some queries are either too fancy or too big to grasp, so our…
Pawel Gerr
entity framework core
Unnecessary Fuzzy Searches may hurt your Entity Framework Core Performance
After talking about performance issues like N+1 Queries and the Cartesian Explosion that made its comeback in Entity Framework Core 3, we will today look at a performance issue that is not tied to any Entity Framework version but is rather a general one. What do I mean by…
Pawel Gerr
entity framework core
The performance issue "Cartesian Explosion" made its comeback in Entity Framework Core 3
In Entity Framework Core 3.0/3.1 the SQL statement generation underwent significant changes. As we have seen in the previous post these changes removed both the implicit client-side evaluation and the N+1 Query Problem (which is good!). Unfortunately, these changes (re)introduced…
Pawel Gerr