我可以删除迁移目录中的 django 迁移文件吗
Can I delete the django migration files inside migrations directory
我个人喜欢 Django，因为它的 MVC 理念。但是当我在 1.7 版中 运行 宁 Django 迁移时，我在其中进行的每一次迁移都存储在迁移目录中。如果我删除这些文件，它会在迁移时引发错误。
我是这样测试的。我创建了一个新的 Django 项目并启动了一个 git 存储库。我 运行 在 Django 中进行了 3-4 次迁移，结果是
migrations目录下有3-4个迁移文件。我尝试删除非常旧的迁移文件，即（第一个和第二个迁移文件）并尝试 运行
python manage.py makemigrations
这确实会导致一些错误，例如 "migration files not found"。后来我做了一个 git stash 来恢复被删除的文件。现在我再次尝试 运行 相同的命令，它工作正常。
我的问题是，如果一个人 运行 在开发过程中对数据库进行了大约 50 次更改，所有迁移文件都存储在迁移目录中。是否可以删除这些文件并在不中断的情况下再次更改数据库？
答案是"it depends"。
如果您使用的是生产数据库，或者某些由于任何原因不能定期删除的数据库，那么您绝对希望保留已应用于数据库的迁移文件。它们应该与您的其余代码一起检入源代码管理。
现在，对于像您这样的情况，放弃 50 次迁移的最简单方法是直接清除数据库（这是 50 次迁移）并根据您当前的模型从头开始。在开发过程中改进模型时，定期执行此操作通常是个好主意。
当你毁掉你的数据库时，毁掉你的模型是可以的，因为 syncdb 将使用你当前的模型构建一个空白数据库。然后它会选择性地使用任何初始固定装置填充数据库。从概念上讲，此时您已不再迁移任何内容，因此您无需保留旧数据库的旧迁移。它们不再相关。
删除已应用于您的数据库的迁移文件通常不好，除非您 1) 完全清除数据库，或 2) 首先恢复迁移。
当您将迁移应用到数据库时，它还会在数据库本身的特殊 table 中记录这些迁移，您可能也会很高兴。这就是为什么当您删除迁移文件时事情会变得一团糟。他们必须与迁移保持同步 table
如果您想保留您的数据库，但减少迁移文件的数量，一种选择是将迁移压缩为一个（或者很少，如果复杂的依赖关系）迁移。
来自官方文档：
You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.
在压缩之前，您应该知道“Django 中的模型相互依赖性会变得非常复杂，压缩可能会导致迁移不会 运行”，并且因此可能需要手动工作。
有关如何进行压缩的详细信息，请参阅文档：https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations
答案是"Do not delete migration files".
要了解为什么我们不应该删除迁移文件，您需要了解迁移在框架中的工作方式。
迁移文件是数据库的历史。根据过去创建的迁移文件创建一个迁移文件。删除迁移文件意味着丢失您的历史记录。此历史信息记录在您数据库的 django_migrations table 中。如果删除迁移文件，则会出现依赖性错误。所以Don't try to lose your history by deleting your migration files.
如果模型与数据库匹配，删除迁移文件是安全的。
目前，使用 Django 3，我可以安全地删除 migrations 目录，然后是 运行 python manage.py makemigrations myapp 和 python manage.py migrate。之后我有了 0001_initial.py 迁移文件，我的生产数据库完好无损。这在模型已经与数据库匹配时有效。
这可能不是一个好主意（显然），但如果你打算这样做......
不要删除 __init__.py 个文件。
在 *nix 中：
cd [your project directory]
find . -path "*/migrations/[0-9][0-9][0-9][0-9]_*.py" -delete
find . -path "*/migrations/*.pyc" -delete
在我看来，这不是个好主意。如果您犯了错误，您可以随时回滚迁移。此外，当迁移变得太大时，您还可以“压缩”它们。我从 DoorDash 写的一篇文章中了解到这一点。
You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.
压缩迁移：https://docs.djangoproject.com/en/3.2/topics/migrations/#squashing-migrations
DoorDash 文章：https://doordash.engineering/2017/05/15/tips-for-building-high-quality-django-apps-at-scale/
我个人喜欢 Django，因为它的 MVC 理念。但是当我在 1.7 版中 运行 宁 Django 迁移时，我在其中进行的每一次迁移都存储在迁移目录中。如果我删除这些文件，它会在迁移时引发错误。
我是这样测试的。我创建了一个新的 Django 项目并启动了一个 git 存储库。我 运行 在 Django 中进行了 3-4 次迁移，结果是 migrations目录下有3-4个迁移文件。我尝试删除非常旧的迁移文件，即（第一个和第二个迁移文件）并尝试 运行
python manage.py makemigrations
这确实会导致一些错误，例如 "migration files not found"。后来我做了一个 git stash 来恢复被删除的文件。现在我再次尝试 运行 相同的命令，它工作正常。
我的问题是，如果一个人 运行 在开发过程中对数据库进行了大约 50 次更改，所有迁移文件都存储在迁移目录中。是否可以删除这些文件并在不中断的情况下再次更改数据库？
答案是"it depends"。
如果您使用的是生产数据库，或者某些由于任何原因不能定期删除的数据库，那么您绝对希望保留已应用于数据库的迁移文件。它们应该与您的其余代码一起检入源代码管理。
现在，对于像您这样的情况，放弃 50 次迁移的最简单方法是直接清除数据库（这是 50 次迁移）并根据您当前的模型从头开始。在开发过程中改进模型时，定期执行此操作通常是个好主意。
当你毁掉你的数据库时，毁掉你的模型是可以的，因为 syncdb 将使用你当前的模型构建一个空白数据库。然后它会选择性地使用任何初始固定装置填充数据库。从概念上讲，此时您已不再迁移任何内容，因此您无需保留旧数据库的旧迁移。它们不再相关。
删除已应用于您的数据库的迁移文件通常不好，除非您 1) 完全清除数据库，或 2) 首先恢复迁移。
当您将迁移应用到数据库时，它还会在数据库本身的特殊 table 中记录这些迁移，您可能也会很高兴。这就是为什么当您删除迁移文件时事情会变得一团糟。他们必须与迁移保持同步 table
如果您想保留您的数据库，但减少迁移文件的数量，一种选择是将迁移压缩为一个（或者很少，如果复杂的依赖关系）迁移。
来自官方文档：
You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.
在压缩之前，您应该知道“Django 中的模型相互依赖性会变得非常复杂，压缩可能会导致迁移不会 运行”，并且因此可能需要手动工作。
有关如何进行压缩的详细信息，请参阅文档：https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations
答案是"Do not delete migration files".
要了解为什么我们不应该删除迁移文件，您需要了解迁移在框架中的工作方式。
迁移文件是数据库的历史。根据过去创建的迁移文件创建一个迁移文件。删除迁移文件意味着丢失您的历史记录。此历史信息记录在您数据库的 django_migrations table 中。如果删除迁移文件，则会出现依赖性错误。所以Don't try to lose your history by deleting your migration files.
如果模型与数据库匹配，删除迁移文件是安全的。
目前，使用 Django 3，我可以安全地删除 migrations 目录，然后是 运行 python manage.py makemigrations myapp 和 python manage.py migrate。之后我有了 0001_initial.py 迁移文件，我的生产数据库完好无损。这在模型已经与数据库匹配时有效。
这可能不是一个好主意（显然），但如果你打算这样做......
不要删除 __init__.py 个文件。
在 *nix 中：
cd [your project directory]
find . -path "*/migrations/[0-9][0-9][0-9][0-9]_*.py" -delete
find . -path "*/migrations/*.pyc" -delete
在我看来，这不是个好主意。如果您犯了错误，您可以随时回滚迁移。此外，当迁移变得太大时，您还可以“压缩”它们。我从 DoorDash 写的一篇文章中了解到这一点。
You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.
压缩迁移：https://docs.djangoproject.com/en/3.2/topics/migrations/#squashing-migrations DoorDash 文章：https://doordash.engineering/2017/05/15/tips-for-building-high-quality-django-apps-at-scale/