使用EF Core的Code First，在设计阶段，直接使用Database.EnsureCreated()和EnsureDeleted()可以快速删除、更新最新的数据结构。由于没有什么数据，删除的风险非常低。但是对于已经投入生产的数据库，这个方法就绝对不可行了。
考虑以下场景： 项目已经上线，一直使用本地测试数据库进行开发，本地已经增加和修改了较多数据库表结构，线上数据庞大且实时更新，现在测试完毕需要进行上线。
如果需要更新生产数据库，我能想的有两种方法：
从一开始就使用Migration
从数据库开始设计的时候，就使用EF Migration，保证数据库能够与代码同步，不过操作的时候，需要极为小心，务必要检查生成的更新数据库代码，直接连接生产数据库，
需要注意的事项：
- 从一开始就使用
Migration，任何时候都不要使用Context.Database.EnsureCreated或者EnsureDeleted语句。 - 使用
Add-migration之后，不要删除生成的Migration文件，这些文件记录了数据结构的变化历史。 - 并不是所有的变化都能自动识别，比如“修改表列名称大小写”，这种情况很多时候生成的数据是执行删除然后再新建，和我们重命名的初衷相去甚远。因此要特别检查migrationBuilder.Drop相关的页面。
使用Scaffold
如果一开始就没有使用migration进行同步的话，那么使用EF Core将无法直接更新，我们需要变通一下：
逆向数据库到模型
首先需要数据库的数据结构逆向到模型，我们使用Scaffold就可以了，详细文档就可以查看这里，需要注意的是，我们的场景下，已经有修改好的DataContext与Model，在进行scaffold的过程中，一定要指定outputdir和context，不要和当前的文件冲突。
根据自己的喜好，选择是否采用-DataAnnotations，另外也可以使用-table指定需要修改的表，没有被指定的表，将保持原样。默认EF Core会按照自己的命名规则重新命名，如果你想保留自己的套路，那么使用-UseDatabaseNames参数。
Add-Migration
输出的模型我指定放在Models文件夹，原来的Models文件夹，我改成了Models1，并且更换了命名空间以保证项目现在能够正常编译。
- 导出的模型与DbConext：Models.Models命名空间，Models文件夹
- 新模型与DbConext：Models命名空间，Models1文件夹
接下来运行
Add-Migration。
add-migration initialcreate -context exportedContext
这样会在Migrations文件夹下面生成一个snapshot和一个migration文件。snapshot是当前数据库的跟踪，另外一个是运用update-database时系统会执行的操作。里面有一个Up()和一个Down()方法，Up是执行更新时EF对数据库的操作，Down是回滚当前更改。由于这是第一次执行add-migration，EF Core会认为数据库现在还是空的，因此两个方法都有大量的语句，我们删除所有create和drop相关的语句，我这边是全部删除了，只留下空方法。
应用迁移，同步
前面准备工作已经到位了，这一步将直接操作数据库了。使用update-database将当前的migration更新到数据库，由于我们现在的数据结构和生产数据库的数据结构一模一样，实际上我们不需要执行什么操作（删除了Up、Down内部的代码），执行Update-Database只是让EF Core将Models和生产数据库建立联系。
我理解只是添加
__EFMigrationsHistory中的记录，以便EF Core后续追踪。
修改模型内容
将Models1中的文件覆盖Models中的文件，由于类型命名的差异，可能会提示一些错误，按照自己的习惯修改就好了。接下来是循序渐进，一点点修改模型，并经常add-migration，观察生成的语句是否正常。
由于我使用了Identity，在数据中有对应的AspNet开头的表，这些表我并不在本系统中使用（其他系统需要用），因此我删除了对应的模型、snapshot、DbContext记录，运行Add-Migration，生成了如下文件：
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropTable(
name: "AspNetRoleClaim");
migrationBuilder.DropTable(
name: "AspNetUserClaim");
migrationBuilder.DropTable(
name: "AspNetUserLogin");
migrationBuilder.DropTable(
name: "AspNetUserRoles");
migrationBuilder.DropTable(
name: "AspNetUserToken");
migrationBuilder.DropTable(
name: "AspNetRole");
migrationBuilder.DropTable(
name: "AspNetUser");
}
说明现在已经能够正常跟踪我们的修改了，不过我这里需要保留对应的表，因此删除up与down的所有内容。
注意以下几点：
更新模型名称
如果使用fluentAPI，那么模型对应的表名称会直接在fluentAPI中直接指定，只修改模型的名称没有任何效果。修改的话，可以修改对应的fluentAPI，或者换用Annotation
提示找不到constraint
对于修改主键、索引等内容的情况，如果不是通过EF Core建立的数据库，那么命名规则可能不一样。对于postgresql数据库，可以用这个查询名称，然后修改对应的migration文件内容即可。
SELECT * FROM pg_CONSTRAINT
复合主键的限制
对于使用两列或者以上列作为复合主键的情况，使用EnsureCreated方法是可以识别Annotation形式的主键的。
[Key]
[Column(Order = 1)]
public string DeviceId { get; set; }
[Key]
[Column(Order = 2)]
public long Timestamp { get; set; }
使用Migration的时候，这种形式无法识别，需要在OnModelCreating()中，使用fluentAPI：
modelBuilder.Entity<DeviceData>().HasKey(w => new { w.DeviceId, w.Timestamp });
Command执行超时
默认Command执行的超时设置只有30s，对一些大一点的表来说，是不太够的。可以设置：
optionsBuilder.UseNpgsql("Server=xxxxxxxxxxxxx", opt=>opt.CommandTimeout(3000));
增加命令执行的超时时间。
多个连接字符串的情况
如果程序使用了appsettings.Development.json之类的文件存储连接字符串，那么需要指定环境是Production（生产数据库），否则可能还原到本地数据库去了。
对于nuget包管理控制台（使用update-database)，执行：
$Env:ASPNETCORE_ENVIRONMENT = "Development"
Update-Database
对于使用dotnet ef工具集的，直接执行：
dotnet ef database update --environment Development
cannot be cast automatically to type
设计数据库表如果修改列的数据类型（比如从varchar到integer），Postgresql会提示这个问题，导致无法修改。可以在migrationbuilder中使用sql，按照提示添加"USING "x"::integer"解决。但是这种方法还是不太优雅，手动处理Up()之后，还需要处理Down()，否则将无法正确还原。
可以使用分步的方法进行，假设我们需要将Id从varchar改成int4。
- 添加一个字段temp，类型为int4，设置为[Key]，然后删除Id字段。
- 添加并应用迁移
- 修改temp名称为Id
- 添加并应用迁移
多次应用迁移
每次修改尽量少一点，然后update-database，这样更容易发现问题，对于有
这种提示的，一定要检查生成语句中Drop相关的语句。
本地数据库与生产数据库，都有__EFMigrationsHistory记录相关的迁移情况。在生产与本地数据库中进行切换是，不用担心顺序问题，Update-Database会一个个应用迁移直到最新。
总结
使用Migration能够降低数据库同步中很多工作量，合理利用，可以对生产用的数据库进行热更新。
注：本文在.NET 6，EF Core 6下测试通过。
标签：
留言评论