EF Core中Update-Database无变更后add-migration触发数据丢失警告咨询

核心底层逻辑差异 #

Add-Migration和Update-Database两个命令的比对基准完全不同，是该问题的根本原因：

• Update-Database的比对逻辑：仅校验数据库中__EFMigrationsHistory表的迁移记录，和本地已存在的迁移文件列表是否一致。只要所有本地已生成的迁移都已经被应用到数据库，就会返回无变更、数据库已为最新的提示。该命令不会直接比对当前实体模型和数据库的实际结构，也不会校验模型和迁移快照的一致性。
• Add-Migration的比对逻辑：会直接将当前最新的实体模型，和最近一次迁移生成的ModelSnapshot快照文件做全量比对，所有两边不一致的修改，不管是什么时间产生的，都会被脚手架生成到新的迁移文件中。

常见触发场景 #

你遇到的历史字段变更被带到新迁移的情况，基本都是以下场景之一导致的：

• 之前修改对应字段的类型后，没有立刻执行Add-Migration生成对应的迁移文件，就直接执行了Update-Database，此时没有新迁移需要应用，自然返回无变更提示，但模型和快照的差异已经存在，下次执行Add-Migration时就会被捕获。
• 多人协作时，拉取了其他人提交的实体修改代码，但没有同步拉取对应的迁移文件，或是本地手动修改了实体后忘记生成迁移，后续新增迁移时就会把这段未被记录的历史变更合并到新迁移中。
• 之前已经生成过对应字段变更的迁移文件，但后续手动删除了迁移文件，却没有回滚对应的ModelSnapshot快照，导致快照和实际模型存在遗留差异，新增迁移时会重新生成对应的AlterColumn操作。

提示数据丢失的原因 #

控制台输出的An operation was scaffolded that may result in the loss of data提示，是因为EF Core检测到本次AlterColumn操作属于字段类型收窄（比如从长字符串改短字符串、从可空改非可空、从高精度数值改低精度数值），可能会导致已有数据截断或丢失，因此提醒你手动核对迁移的准确性。

解决方案 #

• 如果你确认该字段类型变更已经手动同步到数据库，不需要再次应用，可以直接删除新生成迁移文件中无关的AlterColumn代码段，再执行Update-Database即可。
• 如果该变更还未应用到数据库，核对字段修改符合预期后，直接正常应用迁移即可。
• 日常开发中每次修改实体后立刻生成对应迁移，不要攒多个修改再生成迁移，多人协作时同步提交迁移文件和快照文件，不要随意删除已生成的迁移文件，可避免该类问题。

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