将迁移应用到真正不同步的数据库

Question

我继承了一个状况相当糟糕的数据库。基本上有以下几点：

• 大多数应用程序没有迁移文件夹或过时的文件夹
• 南迁历史表与数据库不同步
• 数据库表与 Django 中的当前模型不匹配（尽管我知道模型和表之间发生了什么变化）

我不担心保留过去的迁移历史或类似的事情，但我确实需要保留数据库中当前的数据。我正在寻找一种方法来声明当前数据库状态为初始状态并从那里继续前进。如果有必要，我可以修改模型，以便数据库表与当前模型匹配，因为我认为这是开始的必要条件。

我已经搞砸了几个小时了，如果有任何建议可以解决这个问题，我将不胜感激。

补充说明：

• 数据库使用的是sqlite
• 迁移到 Django 1.8 已摆在桌面上，但还需要几个月的时间

Answer 1

带有 South 的 django 1.6 说明

我建议下载数据库的转储（或在架构中），并使用 sqllite 在本地计算机上创建一个新数据库。

然后删除所有应用程序中所有现有的

/migrations

文件夹 然后删除数据库表中的所有内容

south_migrations

现在禁用数据库中没有的所有“新”模型更改

然后再次进行初始迁移

./manage.py schemamigration myapp --initial

然后全部伪造，因为结构已经存在

./manage.py migrate --fake

现在您的迁移已与生产数据库同步。

现在重新启用新模型更改，然后创建迁移每个应用程序

./manage.py schemamigration myapp

然后迁移到新的更改

./manage.py migrate

注意：在您的服务器和开发计算机上，您需要确保在创建任何新迁移之前删除“迁移”文件夹中的所有旧 .pyc 文件。

根据上面 e4c5 的评论，当你迁移到 django 1.7/1.8 时，你将不得不再次执行其中一些步骤（因为 South 在 1.7 中集成到 Django 中），因此你可能需要考虑同时升级到 1.7时间（尽管这不一定是微不足道的升级......）。

Answer 2

尽管这是一篇旧文章，但我发现解决我们面临的问题很有启发： 在开发端执行了几次迁移并在登台测试后，devops 要求开发团队通过将迁移添加到 .gitignore 来从存储库中删除迁移（由于本地 sqlite 和使用 MariaDB 的 devops 登台环境之间存在一些不兼容性 - 这不是最佳实践，与 django 指南工作流程推荐的相反 https://docs.djangoproject.com/en/4.2/topics/migrations/ ）。 DevOps 团队将运行 makemigrations 并在临时环境上进行迁移，一切都会好起来的。然而，开发团队并没有每次都重置迁移文件夹，因此本地开发迁移中存在累积的更改，这些更改未在暂存中复制。在登台期间，这不是问题，因为 DevOps 团队可以重置登台数据库而不会产生任何后果。但是，在设置生产并存在生产数据后，迁移和数据库无法以相同的方式同步。

为了解决这个问题，我们必须回顾我们的 DevOps 指南。我们将来自开发的迁移保留在存储库中，解决开发过程中的所有 MariaDB 问题（即字符字段的限制等）。最终，迁移可以从开发中被压制。

为了解决生产数据库中的错误同步问题，我们伪造了所有迁移，然后从数据库 django_migrations 表中删除，这些迁移包含最新的架构更改（而不是回滚，因为这些架构未应用，因此会给出错误） 。在此阶段，数据库和迁移已同步，只需应用最新的迁移。 有用的命令： ''' python 管理.py showmigrations ./manage.py makemigrations # ==> 未检测到任何更改 ./manage.py migrate --fake # ==> 这将标记 django_migrations 表中的所有迁移

从数据库中删除数据库中不存在的“新”模型更改的 django_migrations

./manage.py migrate # ==> 以便应用最新的架构更新。

'''