【问题标题】:Django South Migration does not work the first time aroundDjango South Migration 第一次不起作用
【发布时间】:2013-07-17 17:01:30
【问题描述】:

我正在运行南迁移python manage.py syncdb; python manage.py migrate --all,在新数据库上运行时会中断。但是,如果您运行它两次,它会正常运行!在第一次尝试时,我得到了

DoesNotExist: ContentType matching query does not exist. Lookup parameters were {'model': 'mymodel', 'app_label': 'myapp'}

失败后进入数据库select * from django_content_type果然有

13 | my model     | myapp      | mymodel  

然后我运行迁移python manage.py syncdb; python manage.py migrate --all,它可以工作了!

那么,我是如何设法进行只能在第二次运行的迁移?顺便说一句,这是一个数据迁移,它将适当的组放入管理应用程序中。迁移中的以下方法正在破坏它:

@staticmethod
def create_admin_group(orm, model_name, group_name):
    model_type = orm['contenttypes.ContentType'].objects.get(app_label='myapp', model=model_name.lower())
    permissions = orm['auth.Permission'].objects.filter(content_type=model_type)
    group = orm['auth.Group']()
    group.name = group_name
    group.save()
    group.permissions = permissions
    group.save()

(迁移文件来自一个现有的工作项目,这意味着很久以前我已经运行了 schemamigration --initial。我只是试图将数据库模式和初始数据复制到一个新的数据库中。)

【问题讨论】:

  • 我有几个这样的,我相信这是因为当它第一次尝试运行迁移时,模型尚未创建;并且在该位失败后创建它。下次因为模型在那里它运行良好
  • 那么这是否被认为是南方的一个错误?我希望迁移将按顺序运行

标签: python django django-south


【解决方案1】:

原来这是南方的一个错误。

http://south.aeracode.org/ticket/1281

【讨论】:

    【解决方案2】:

    当然会是这样,您还没有进行任何初始架构迁移。正确的方法是这样的:

    1. 首先使用south 注册您的django 应用程序。比如:
      python manage.py schemamigration --initial <app_name>.
    2. 然后运行manage.py syncdb
    3. 在此之后,您运行migrate 就像python manage.py migrate <apps>,请注意,只需运行migrate 只会迁移您所有注册的应用程序。我倾向于这样做。
    4. 如果您更改模型以更改架构,那么您可以简单地使用:
      manage.py schemamigration --auto

    你提到的问题是这个。一旦你运行syncdb,你已经得到了一个板条箱,南方与此无关。因此,您要做的是查询没有迁移控制 (iirc) 的数据库。

    【讨论】:

    • 我试着按照你说的去做,但是没有用。在第 2 步失败:DatabaseError: 关系“south_migrationhistory”不存在。
    • 我现在意识到我可能没有提供足够的信息。我已经运行了 schemamigration --initial。我只是试图将工作迁移历史部署到新服务器上。
    • @Mark:我的错,在第 2 步之前执行第 3 步。
    • 好吧,在那种情况下,我一直按该顺序运行命令,但仍然失败。
    • @Mark:好吧,我很快就会对此进行截屏。所以,我会尽可能更新这个。同时检查一下:south.readthedocs.org/en/latest/tutorial/part1.html
    【解决方案3】:

    第一次发出python manage.py syncdb; python manage.py migrate --all 是一种不好的做法。首先,我不太相信--all 选项。它可能包括 Django 的官方库,您当然不希望这样,即使 没有什么可以迁移。我宁愿去python manage.py migrate <app_name1> <app_name2> ...

    但是对于 South 来说,使用 South 的方式是:

    1. 创建应用
    2. 使用python manage.py schemamigration --initial <app>为其创建迁移
    3. 使用python manage.py convert_to_south <app> --auto 转换为南和现有迁移
    4. 对应用程序进行一些修改,然后python manage.py migrate <app>

    您的方法可能确实有效,但请注意,当您执行migrate --all 时,您无法控制应用迁移的顺序,并且python manage.py syncdb 不会保证您访问的contentType 是(myapp,mymodel ) 当时可用。

    该错误仅在第一次出现,因为迁移实际上可能只应用了一次。并在 south_migrationhistory 表中保存已应用,因此当您再次发出命令时,它会忽略它。

    我的建议是,在 syncdb 命令之后首先迁移目标应用程序。如果这不起作用或事情变得混乱,试试这个:

    1. INSTALLED_APPS 中评论'south',
    2. 问题python manage.py syncdb
    3. #'south', 中的INSTALLED_APPS 行中删除注释
    4. 发出最终命令python manage.py migrate --all

    祝你好运,希望这会有所帮助!

    【讨论】:

    • 迁移失败的原因不是因为 --all 标志,也不是因为 south_migrationhistory 表中的错误。这是因为 South 有一个 bug,没有正确处理 contenttypes 表。
    • @Mark:很棒的发现,很遗憾让你认为我的回答值得一票否决。
    • 感谢您的回答;我认为这将帮助那些正在创建他们的第一次迁移的人,但这不是我问题的正确答案,我不希望人们被误导。对不起!
    猜你喜欢
    • 2014-02-25
    • 2012-05-18
    • 1970-01-01
    • 2011-06-10
    • 2012-02-21
    • 1970-01-01
    • 2017-07-31
    • 2020-04-16
    • 2018-10-25
    相关资源
    最近更新 更多