migrations - Django 1.8:为现有模式创建初始迁移




python manage.py migrate报错 (4)

如果您使用的是路由器,可能会出现问题。 检查方法 allow_migrate 如果它在 routers.py 中以正确的方式执行。 尝试将返回值始终设置为 True ,并检查它是否解决了问题,

def allow_migrate(self, db, app_label, model_name=None, **hints):
    return True

我启动了一个使用迁移系统的django 1.8项目。
在某种程度上事情变得混乱,所以我从数据库中删除了迁移文件夹和表,现在我正在尝试重建它们,但没有成功。

我有三个应用程序(3个 models.py 文件),模型完全反映了表格!

到目前为止我发现的最佳方法是:

  1. 清除所有 migrations 文件夹。 完成!
  2. django_migrations 表中删除所有内容。 完成!
  3. 为每个应用程序运行 python manage.py makemigrations --empty <app> 。 完成!
  4. 运行 python manage.py migrate --fake 。 完成! (虽然只有在每次 makemigrations 命令之后运行它才 makemigrations

现在我添加一个新字段,运行 makemigrations 命令,我收到以下错误:
django.db.utils.OperationalError: (1054, "Unknown column 'accounts_plan.max_item_size' in 'field list'")

我一直在烧这个东西。 我怎样才能初始化迁移,这样我每次都可以继续工作而不会发生迁移中断?

为什么这么复杂? 为什么没有一个简单的单行: initiate_migrations_from_schema

编辑:
现在事情变得更加糟糕了。 我截断了 django_migrations 表并删除了所有 migrations 文件夹。
现在我尝试运行 python manage.py migrate --fake-initial (我在DEV文档中找到的东西),这样就设置了所有Django的“内部”应用程序(auth,session等),我得到了:
(1054, "Unknown column 'name' in 'django_content_type'")
现在,这个“专栏”不是一个真正的专栏。 这是在Django的 contenttypes 应用程序中定义的 contenttypes 。 这里发生了什么? 为什么将 name 属性标识为真正的列?


我遇到过这种情况,但我从来没有丢弃数据库来解决它。 通常,我从应用程序中删除迁移文件夹,并从数据库中删除迁移条目。

我会尝试一次运行一个应用程序进行迁移。 如果任何应用程序依赖于其他表,显然最后添加它们。

另外我通常只运行, python manage.py makemigrations 然后只是 python manage.py migrate 即使初始迁移它也应该可以正常使用Django 1.7和1.8。


谢谢 - 我一直在研究这个问题,你的最佳实践列表非常方便。 这可能有助于新手像我这样的python:

如果您从一组现有模型开始,请清除以前的任何迁移!

我的情况是我开始使用sqlite只是为了理解django然后切换到一个mysql数据库 - 并且它不断抛出1053错误,可能试图应用之前的迁移它没有资源来解决...


django ...,1.8,1.9,...

您想要实现的目标是压缩现有迁移并使用替换它们。

如何在发布时不使用任何命令正确地执行它(对数据库和同事没有影响的情况)。

  1. 对于每个应用,请删除其迁移文件夹: mv <app>/migrations/ <app>/migrationsOLD/

  2. 对于每个应用程序运行: python manage.py makemigrations <app>

  3. 自定义每个新迁移:

    • 如果你有一个 复杂的应用程序 ,或者它们之间有更多的应用程序和相关模型,为了避免 CircularDependencyErrorValueError: Unhandled pending operations for models

      <app> 0002_initial2.py 准备第二次空迁移(将依赖项放在 app_other::0001_initial.py<app> :: 0001_initial.py - 所有ForeignKey,M2M与在其他应用程序中的0001迁移步骤中创建的模型相关)

      一切都必须井然有序 - 有时需要更多的迁移准备。 在每个迁移中处理 dependencies 属性。

    • 处理初始值 - 验证来自 migrationsOLD 所有 RunPython 操作,并在需要时将代码复制到新的初始迁移。

    • --fake-initial 可选)为所有新的迁移类添加 initial=True (如果已添加,则为0002)。

    • 在新的迁移类中添加 replaces 属性。 (就像自己定制的 squashmigrations )。 从 <app> 放置所有旧迁移
  4. 使用 makemigrations 验证所有 makemigrations

    断言“未检测到任何变化”

  5. 检查是否在任何地方 migrate -l show [x]

    断言相似:

    [X] 0001_initial

    [X] 0002_initial2(102次压缩迁移)

例:

对于旧的:

0001_initial.py
0002_auto.py
...
0103_auto.py

准备:

0001_initial.py
0002_initial2.py  (optional but sometimes required to satisfy dependency)

并添加到最后一个 replaces (0002这里,可以是0001):

replaces = [(b'<app>', '0002_auto.py'), ..., (b'<app>', '0103_auto.py')]

0001_initial.py的名称应与旧名称相同。

0002_initial2.py是新的,但它是旧迁移的替代品,因此Django会将其视为已加载。





django-migrations