如何解决由于迁移文件名更改导致的数据库迁移错误？答案

【问题标题】：How do I resolve database migration error due to changed migration filename?如何解决由于迁移文件名更改导致的数据库迁移错误？
【发布时间】：2021-12-30 15:28:33
【问题描述】：

我对 Python 和 Django 还是很陌生，所以我有一种情况我不知道如何解决。

主要问题是，在将我的代码部署到 dev 时，部署失败，到 stage 或 prod，它通过了。

我处理了一个问题，即我必须在我们的应用程序的表中删除一些列。进行更改后，我部署到 dev 并要求进行代码审查。在代码审查中，建议我将迁移文件的名称更改为更具描述性的名称，而不是仅仅将其保留为 0018_auto_。

我进行了更改并部署到 dev 和 stage。开发失败（当我预计它会成功时）因为看到了新名称并且 django 试图删除不再存在的列。在阶段，名称从未更改，并且第一次使用该文件的新名称删除了列。

所以舞台部署得很好。

如何在 dev 上解决此错误，以便它识别此迁移已经发生？

谢谢！

【问题讨论】：

听起来迁移失败不是因为文件名更改了，而是因为您已经手动进行了迁移。您可以将列放回去，或者如果您确定您手动进行了正确的迁移，您可以 --fake 迁移，或者您可以手动将迁移输入到 django_migrations 表中，或者您可以注释掉迁移然后运行它...
感谢 Jimmy 的评论，我一直在阅读有关 —fake 的信息，但我仍然不知道如何使用它。您能否通过示例或带有代码示例的文章启发我？我认为这就是我所需要的。没错，我在 dev 上使用旧文件名进行了迁移，然后进行了更改。因此，它确实已经成功迁移到 dev 中。我想我可以阅读这些专栏，但我想先看看是否有更简单的方法。
如果第一次迁移在旧文件名下成功运行，那么您需要先撤消或修复它。您可以通过撤消迁移来撤消迁移docs.djangoproject.com/en/3.2/topics/migrations/…，或者您可以只更改存储在 django_migrations 表中的值
感谢您指出这一点。我明天试试反转。
所以你在第一条评论中给我的想法最终是我需要做的。在部署到 gitlab 时，我不知道如何使用 Django 和 Zappa 运行 --fake。我也访问了 AWS RDS，但没有办法编辑那里的表格（我不太精通 AWS）。最后，我编辑了我最新的迁移文件，而不是 RemoveField，我将它们全部添加回来并部署到 dev。之后，我再次编辑文件以删除以及更新模型和序列化器和 bam，现在看起来很棒！非常感谢！

标签： python django database deployment database-migration

【解决方案1】：

如果您 100% 确定为 0018 所做的唯一更改是文件名，并且这是您应用的最后一次迁移，您可以：

python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18
python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename

这将保留0018 中存在的更改，并将更改应用到文件名。

【讨论】：

感谢您的评论和解释，这实际上对我的本地测试非常有用，但是当通过 django 和 zappa 在开发中的 gitlab 上使用 --fake 时，它没有成功，我使用这种方法无法弄清楚。不过我确实成功了，我会在上面发布答案。
一切顺利！我已经有一段时间没有使用 zappa，但是回顾一下 docs（以及供我们将来参考），您应该能够在您的开发部署中执行此操作：zappa manage dev migrate myapp 0017 --fake 等等。
是的，我尝试了该命令和其他一些排列。在 gitlab.yml 中没有解决，但我很感激。我会在底部添加对我有用的东西，基本上是很长的路

【解决方案2】：

Django 构造一个名为djang_migrations 的表，用于跟踪已应用的迁移。如果您稍后更改了迁移文件的名称，那么它将看起来好像该迁移没有运行。

您可以在开发环境的django_migrations 表中重命名迁移：

UPDATE django_migrations
SET name = '0018_new_name'
WHERE app = '%%%name_of_the_app'
  AND name = '0018_auto_'

其中 0018_new_name 是迁移文件的新名称。

通过更新此名称，Django 现在应该认为新的迁移文件已完成。

【讨论】：

感谢您的评论，虽然这应该可行，但我无法找到该表：D 我必须等待我的后端好友从假期回来并检查访问该表的位置。我们还使用 Django 和 Zappa，所以在所有情况下设置都不是很清楚，这就是我求助于你们的原因。感谢您的帮助！

【解决方案3】：

所有这些都是很好的答案，无疑会在现在和将来帮助其他人！

我尝试了所有这些答案，但只有一件事有效。任重而道远！

为了获得全面的可见性（这在本地工作，我明白 --fake 现在在实践中，感谢@brian-destura！）：

python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18
python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename

在通过 gitlab 进行部署时，我们的 django / zappa 应用只是不想成功部署（即使尝试了许多不同的解决方案）。

最后，解决此问题的唯一方法是更新 0018 迁移文件以添加回所有这些字段，回滚模型和序列化程序中的更改，然后重新部署到 dev。

之后，恢复所有这些更改，包括迁移文件，并再次重新部署到 dev。

可能有一些更简单的方法可以做到这一点，但是所有那些拥有更多后端知识的人都会在假期外出（我最初是一个前端，在去年拥有更多的后端知识/项目），我很高兴解决并发布我的更改。

感谢你们提供了一些可以尝试的东西、想法和定义知识，我可以用它来创建我自己的冗长解决方案！

【讨论】：