我个人喜欢django的MVC理想。但是当我在1.7版本中运行Django迁移时,我在其中进行的每次迁移都存储在迁移目录中。如果我删除这些文件,它会在迁移时抛出错误。
我像这样测试过。我创建了一个新的Django项目,并发起了一个git repo。我在Django中运行了3-4次迁移,结果导致了 迁移目录下的3-4个迁移文件。我尝试删除较旧的迁移文件,即(第一和第二个迁移文件)并尝试运行
python manage.py makemigrations
确实会导致“找不到迁移文件”等错误。后来我做了一个git stash,恢复了删除的文件。现在我试图再次运行相同的命令,它工作正常。
我的问题是,如果一个人在开发期间在db中运行了大约50个更改,则所有迁移文件都存储在迁移目录中。是否可以删除这些文件并再次对db进行更改而不会中断?
答案 0 :(得分:9)
答案是"它取决于"。
如果您正在使用生产数据库或某些因任何原因无法定期吹走的数据库,那么您绝对希望保留已应用于数据库的迁移文件。应该使用其余代码将它们检入源代码管理中。
现在,对于像你这样的情况,丢弃50次迁移的最简单方法就是放弃数据库(以及它的50次迁移),并在给定当前模型的情况下从头开始。在开发过程中进化模型时,定期执行此操作通常是个好主意。
当你吹掉你的数据库时,可以吹走你的模型,因为syncdb将使用你当前的模型构建一个空白数据库。然后,它可以选择使用任何初始灯具填充数据库。从概念上讲,您不再需要在这一点上迁移任何内容,因此您不需要为旧数据库保留旧迁移。它们不再相关。
删除已应用于您的数据库的迁移文件通常不太好,除非您要么完全放弃数据库,要么2)首先恢复迁移。
您可能还希望知道,当您将迁移应用于数据库时,它还会将这些迁移记录在数据库本身的特殊表中。这就是为什么当您删除迁移文件时,事情会变得混乱的原因。他们必须与迁移表保持同步
答案 1 :(得分:0)
如果您想保留数据库,但减少迁移文件的数量,一个选项是将迁移压缩为一个(或少数,如果是复杂的依赖项)迁移。
来自官方文件:
我们鼓励您自由地进行迁移,而不用担心您拥有多少迁移;迁移代码经过优化,可以一次处理数百个迁移代码而不会出现太大的减速。然而,最终你会想要从几百次迁移回到几次迁移,这就是挤压的地方。
在压缩之前,您应该知道“Django中的模型相互依赖性会变得非常复杂,压缩可能会导致无法运行的迁移”,因此可能需要手动工作。
有关如何进行挤压的详细信息,请参阅文档:https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations
答案 2 :(得分:0)
答案是"Do not delete migration files".
要了解我们不应删除迁移文件的原因,您需要了解迁移在框架中的工作原理。
迁移文件是数据库的历史记录。根据过去创建的迁移文件创建一个迁移文件。删除迁移文件意味着丢失历史记录。此历史信息记录在数据库的django_migrations表中。如果删除迁移文件,则会出现依赖性错误。所以Don't try to lose your history by deleting your migration files.
答案 3 :(得分:0)
如果模型与数据库匹配,则可以安全地删除迁移文件。
当前,使用Django 3,我可以安全地删除 migrations 目录,然后运行python manage.py makemigrations myapp
和python manage.py migrate
。之后,我有了 0001_initial.py 迁移文件,并且我的生产数据库是完整的。当模型已经与数据库匹配时,此方法有效。