通过 Django 模型迁移覆盖表的风险？

Posted 2023-02-24

【中文标题】通过 Django 模型迁移覆盖表的风险？

【英文标题】：Risk to overwrite tables via Django Models migrations?

【发布时间】：2016-12-26 08:19:13

【问题描述】：

我目前正在尝试更新我的 Django 模型以包含一些新功能，但是在运行“makemigrations”之后，控制台输出让我担心我会覆盖数据库中的其他表。

基本上，在我的 models.py 中，我有 8 个模型。一个是全新的，一个只是修改过的。我想将这些更改迁移到数据库，所以我运行“makemigrations”。创建了一个迁移文件（我注意到没有其他文件 - 大概是最初创建这些文件的同事出于某种原因删除了它们）。控制台输出为：

- Create model ModelNew
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelUpdated

为什么说创建模型？是因为据 Django 所知，这是第一次执行迁移吗？或者它是否计划覆盖所有其他表（这会完全杀死我们的应用程序并导致非常糟糕的一天）？

我还注意到一些型号已经指定

db_table = 'some_table'
db_tablespace = 'sometable'

其他人，只是， db_tablespace = 'sometable'

其他，什么都没有。有人对此有什么想法吗？

【参考方案1】：

Django 在进行迁移时不会询问数据库本身；它基于以前的迁移和模型的当前状态构建了一个图表。因此，如果以前没有迁移，Django 将从头开始创建它们。这不会覆盖您的表，但实际上也不会工作，因为它会尝试创建它们而数据库会拒绝。

一种选择是暂时还原您的更改并再次运行 makemigrations 以返回正确的起点，然后使用 --fake-initial 运行该迁移以将其标记为已应用而不实际执行，然后重新应用您的更改并运行 makemigrations再次。

【讨论】：

Django 1.7 支持这个命令吗？ “makemigrations --fake my_app”和“makemigrations --fake-initial my_app”似乎都不起作用。