Entity Framework Core – Changing DB Migration Schema At Runtime

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

In this article:

pg
Pawel Gerr is architect consultant at Thinktecture. He focuses on backends with .NET Core and knows Entity Framework inside out.
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!

Free
Newsletter

Current articles, screencasts and interviews by our experts

Don’t miss any content on Angular, .NET Core, Blazor, Azure, and Kubernetes and sign up for our free monthly dev newsletter.

EN Newsletter Anmeldung (#7)
Related Articles
AI
sg
One of the more pragmatic ways to get going on the current AI hype, and to get some value out of it, is by leveraging semantic search. This is, in itself, a relatively simple concept: You have a bunch of documents and want to find the correct one based on a given query. The semantic part now allows you to find the correct document based on the meaning of its contents, in contrast to simply finding words or parts of words in it like we usually do with lexical search. In our last projects, we gathered some experience with search bots, and with this article, I'd love to share our insights with you.
17.05.2024
Angular
SL-rund
If you previously wanted to integrate view transitions into your Angular application, this was only possible in a very cumbersome way that needed a lot of detailed knowledge about Angular internals. Now, Angular 17 introduced a feature to integrate the View Transition API with the router. In this two-part series, we will look at how to leverage the feature for route transitions and how we could use it for single-page animations.
15.04.2024
.NET
KP-round
.NET 8 brings Native AOT to ASP.NET Core, but many frameworks and libraries rely on unbound reflection internally and thus cannot support this scenario yet. This is true for ORMs, too: EF Core and Dapper will only bring full support for Native AOT in later releases. In this post, we will implement a database access layer with Sessions using the Humble Object pattern to get a similar developer experience. We will use Npgsql as a plain ADO.NET provider targeting PostgreSQL.
15.11.2023