解决Django迁移报错‘Migration is applied before its dependency’

基础问题解答 #

Q1. 删除所有0001_initial相关迁移记录再执行迁移是否安全？若仅为Schema迁移（用fixtures导入数据），此操作是否可行？是否有其他解决办法？ #

• 安全性取决于数据库schema与新版本Django Models的匹配度：如果两者完全一致，删除后通过--fake标记迁移已完成是安全的；如果schema存在差异（比如缺字段、表结构不匹配），这么做会导致后续API或ORM操作报错。
• 仅做Schema迁移且用fixtures导数据的场景：先确认Models与现有数据库schema完全对齐，再删除记录并--fake迁移是可行的。
• 其他解决办法：
  • 先手动补全依赖迁移：比如先执行python manage.py migrate auth --fake 0011_xyz，标记依赖的迁移已完成，再处理abc的迁移。
  • 检查迁移文件的dependencies配置：确认是否有人为修改导致依赖顺序错误，修正后重新执行迁移。

Q2. 重新执行迁移是否安全？若因表/列已存在导致迁移失败，会破坏数据库一致性吗？ #

• 重新执行迁移本身是安全的，Django迁移在PostgreSQL中大多是事务性的：如果因表/列已存在报错，整个迁移事务会回滚，不会修改现有数据或schema，不会破坏一致性。
• 少数非事务性操作（如老版本PostgreSQL中某些ALTER TABLE语句）可能残留部分变更，但这种情况极少，PostgreSQL 9.1+基本支持全量事务迁移。

Q3. 某一迁移失败后，是否会继续执行剩余迁移？ #

• 不会。Django迁移按顺序执行，一旦某一步报错，整个迁移进程立即终止，后续所有迁移都不会执行。

Q4. 迁移失败后能否/应否继续执行剩余迁移？需指定参数吗？ #

• 不应该直接继续执行剩余迁移：前面的迁移是后续的依赖，依赖未完成时，后续迁移大概率会因schema不匹配报错。
• 正确流程：先修复失败的迁移问题（比如用--fake标记已完成的实际schema，或手动回滚非事务性变更），再重新执行python manage.py migrate，无需额外参数。

更新后的问题解决方案（清空django_migrations后--fake成功但API报错字段缺失） #

你遇到的问题是：--fake仅修改了Django的迁移记录，未同步实际数据库schema与Models的差异（比如缺失xyz列），导致API调用报错。针对156张表的批量场景，解决方案如下：

1. 自动对比schema与Models差异
   安装django-extensions，执行python manage.py inspectdb，生成基于现有数据库的Models文件，将其与当前项目的Models对比，导出所有差异（缺失的列、字段类型不匹配等）。

2. 生成针对性迁移脚本

   • 不要重新执行makemigrations生成全量初始迁移，而是针对差异点（比如缺失的xyz列）手动创建迁移文件，或使用makemigrations的增量生成功能：

     python manage.py makemigrations --name add_xyz_column abc
     

     然后编辑生成的迁移文件，确保仅包含新增字段的操作，再执行python manage.py migrate。

3. 使用--fake-initial批量处理
   执行以下命令，Django会自动识别已存在的表并标记对应初始迁移为已完成，仅对Models中新增的字段/表执行实际迁移：

   python manage.py migrate --fake-initial
   

4. 借助第三方工具批量同步
   使用alembic（SQLAlchemy的迁移工具，可与Django配合）自动生成schema差异的迁移脚本，批量执行同步。这种方式适合大量表的场景，能减少手动对比的工作量。

注意：所有schema变更必须通过Django迁移或正规迁移工具执行，禁止直接手动修改数据库，避免后续迁移记录与实际schema再次脱节。

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