多EF托管架构数据库执行Update-Database的问题及优化方法咨询

问题背景 #

使用EF Core代码优先模式在PostgreSQL中管理多架构应用时：

• MyGreatApp1架构已通过迁移创建，连接字符串SearchPath设为该架构，对应__EFMigrationsHistory表存在
• 新建MyGreatApp2应用，连接字符串SearchPath设为MyGreatApp2，执行Update-Database或dotnet ef database update时失败，报错无法读取MyGreatApp2.__EFMigrationsHistory表
• 核心原因是EF Core默认的迁移历史表存在性检查SQL仅判断全库是否有名为__EFMigrationsHistory的表，忽略架构归属，导致因其他架构已有该表，就不创建目标架构的对应表

更优处理方式 #

1. 显式指定迁移历史表的架构（推荐）

在MyGreatApp2的DbContext配置中，明确指定迁移历史表所属的架构，让EF Core精准检测目标架构下的表：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);
    
    // 绑定迁移历史表到MyGreatApp2架构
    modelBuilder.Entity<Microsoft.EntityFrameworkCore.Migrations.HistoryRow>()
        .ToTable("__EFMigrationsHistory", "MyGreatApp2");
}

配置后，EF Core会带上架构条件检查表是否存在，不会误判其他架构的同名表。

2. 自定义迁移历史表检测逻辑（进阶）

如果需要全局适配多架构场景，可重写PostgreSQL的历史仓库逻辑，修正存在性检查SQL：

public class CustomPostgresHistoryRepository : NpgsqlHistoryRepository
{
    public CustomPostgresHistoryRepository(HistoryRepositoryDependencies dependencies)
        : base(dependencies)
    {
    }

    protected override string ExistsSql
    {
        get
        {
            var defaultSchema = Dependencies.CurrentContext.Context.Model.GetDefaultSchema();
            return $@"SELECT EXISTS (SELECT 1 
                    FROM pg_catalog.pg_class c 
                    JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace 
                    WHERE c.relname = '{TableName}' AND n.nspname = '{defaultSchema}');";
        }
    }
}

然后在DbContext的配置中替换默认服务：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseNpgsql("YourConnectionString")
        .ReplaceService<IHistoryRepository, CustomPostgresHistoryRepository>();
}

这种方式从根源上解决了多架构下的检测问题，适合有多个多架构应用的场景。

3. 自动化预创建迁移历史表

若不想修改应用代码，可在执行迁移前通过脚本自动创建目标架构及迁移历史表，比如在CI/CD流程或本地执行：

-- 创建目标架构（如果不存在）
CREATE SCHEMA IF NOT EXISTS MyGreatApp2;

-- 创建迁移历史表（如果不存在）
CREATE TABLE IF NOT EXISTS MyGreatApp2.__EFMigrationsHistory (
    MigrationId character varying(150) NOT NULL,
    ProductVersion character varying(32) NOT NULL,
    CONSTRAINT PK___EFMigrationsHistory PRIMARY KEY (MigrationId)
);

执行完脚本后再运行迁移命令即可正常执行。

内容的提问来源于stack exchange，提问作者Rob Quincey