如何移除Django迁移中引用的旧类RefObjModel？最佳方案探讨

最优处理步骤 #

• 先提取RefObjModel.get_create_table_sql()生成的实际SQL语句：在删除模型类之前，通过Python shell执行from buckets.my_models.models import RefObjModel; print(RefObjModel.get_create_table_sql())，把输出的SQL字符串复制下来。
• 创建新迁移替换动态引用：把原有迁移里的sql=buckets.my_models.models.RefObjModel.get_create_table_sql()改成硬编码的SQL，比如sql="CREATE TABLE refobj (id INTEGER PRIMARY KEY, ...)"，确保反向迁移逻辑（这里是noop）不受影响。
• 在所有环境执行新迁移：运行python manage.py migrate，让Django记录该迁移已应用。
• 安全删除RefObjModel类文件：此时所有涉及该模型的迁移操作已替换为静态SQL，不再依赖模型类。
• 可选合并旧迁移：如果旧迁移文件冗余，用python manage.py squashmigrations buckets <迁移编号>把含模型引用的旧迁移和新迁移合并。合并后生产环境需执行python manage.py migrate --fake，标记合并后的迁移为已应用，避免重复执行SQL。

手动删除迁移中模型引用的风险 #

• 若所有环境已应用该迁移：手动把模型引用替换为硬编码SQL，不会影响生产运行或部署——Django仅执行未应用的迁移，已应用的迁移不会重新运行。但要注意：
  • 不能删除迁移文件本身，只能修改内容，否则Django会误判存在未应用迁移，引发错误。
  • 必须保证所有环境的迁移文件完全一致，避免迁移记录不匹配。
• 若有环境未应用该迁移：修改迁移文件会导致这些环境执行迁移失败，因为动态引用被移除后，SQL逻辑可能与原模型生成的不一致，或出现依赖缺失。
• 反向迁移影响：如果原反向迁移依赖模型类，需同步修改为对应静态SQL，否则执行回滚操作时会出错。

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