EntityFramework Core 9.0 中 DropTable 与 CreateTable 组合操作的回归问题分析

在 EntityFramework Core 从 8.0 升级到 9.0 版本后，开发人员发现了一个重要的行为变化：当在同一个迁移操作中连续使用 DropTable 和 CreateTable 方法重建同一个表时，会导致迁移失败。这个问题引起了广泛关注，因为它影响了常见的数据库重构场景。

问题现象

当开发者在迁移代码中编写如下操作序列时：

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.DropTable(name: "Employees");
    
    migrationBuilder.CreateTable(
        name: "Employees",
        columns: table => new
        {
            EmployeeId = table.Column<int>(type: "int", nullable: false)
                .Annotation("SqlServer:Identity", "1, 1"),
            Name = table.Column<string>(type: "nvarchar(max)", nullable: false)
        },
        constraints: table =>
        {
            table.PrimaryKey("PK_Employees", x => x.EmployeeId);
        });
}

系统会抛出 KeyNotFoundException 异常，提示 The given key '(Employees, )' was not present in the dictionary。这表明 EF Core 9.0 在处理表删除和重建操作时，内部状态管理出现了问题。

临时解决方案

开发团队发现了一个有效的临时解决方案：使用原始 SQL 命令替代 DropTable 方法：

migrationBuilder.Sql("DROP TABLE Employees;");

这种方法绕过了 EF Core 的迁移操作处理逻辑，直接执行 SQL 命令，避免了内部状态不一致的问题。

问题根源分析

经过 EF Core 团队调查，这个问题源于 9.0 版本中对临时表(temporal tables)处理逻辑的重大重构。新的实现方式改变了迁移操作生成器内部维护表状态的方式，导致在同一个迁移中删除并重建表时，状态管理出现不一致。

具体来说，当执行 DropTable 操作时，EF Core 9.0 会从内部字典中移除该表的所有相关信息，包括其临时表属性。而当紧接着执行 CreateTable 时，系统尝试访问这些已被移除的信息，导致键不存在的异常。

影响范围

这个问题主要影响以下场景：

1. 需要完全重建表结构的情况
2. 表重命名操作（有时会先删除再创建）
3. 列类型变更等需要完全重建表的操作

值得注意的是，这个问题在 EF Core 8.0 及更早版本中并不存在，属于 9.0 版本引入的回归问题。

官方修复方案

EF Core 团队已经确认了这个问题，并计划在两个版本中提供修复：

1. EF Core 10.0 Preview 3
2. EF Core 9.0.5

修复方案包括两个部分：

1. 对非临时表场景，增强字典访问的健壮性
2. 对临时表处理逻辑进行全面重新设计（仅在 10.0 中提供）

最佳实践建议

在等待官方修复的同时，建议开发者：

1. 对于紧急修复，使用原始 SQL 命令作为临时解决方案
2. 尽量避免在同一个迁移中删除并重建同一个表，考虑分步迁移
3. 对于复杂表重构，考虑使用多步骤迁移策略
4. 在升级到 EF Core 9.0 时，全面测试现有的迁移脚本

总结

这个回归问题提醒我们，在升级 ORM 框架时需要谨慎评估迁移相关功能的变化。EF Core 团队已经确认了问题的严重性并安排了修复计划。对于需要立即解决此问题的项目，使用原始 SQL 命令是一个可靠的临时方案，而长期来看，等待官方修复或升级到包含修复的版本是最佳选择。