关系“django_content_type”的Django列“名称”不存在


Django column “name” of relation “django_content_type” does not exist

在执行迁移(python manage.py migrate)时，我一直收到以下错误：

1
django.db.utils.ProgrammingError: column"name" of relation"django_content_type" does not exist

我已经做了以下尝试，但没有成功：

  • 我已经删除了每个模型的所有迁移文件
  • 删除了django ou迁移中的所有记录
  • 运行python manage.py migrate--假首字母

    • 运行Django 1.8.2。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    python manage.py showmigrations
    admin
     [ ] 0001_initial
    auth
     [ ] 0001_initial
     [ ] 0002_alter_permission_name_max_length
     [ ] 0003_alter_user_email_max_length
     [ ] 0004_alter_user_username_opts
     [ ] 0005_alter_user_last_login_null
     [ ] 0006_require_contenttypes_0002
    contenttypes
     [X] 0001_initial
     [ ] 0002_remove_content_type_name
    hashtags
     [ ] 0001_initial
     [ ] 0002_hashtagvisit_user
    posts
     [ ] 0001_initial
     [ ] 0002_auto_20150530_0715
    sessions
     [ ] 0001_initial
    users
     [ ] 0001_initial

    号

    谢谢你的帮助。

    相关讨论

    我今天遇到了同样的问题，我想添加一个问题摘要以及如何解决它：

    问题来源：

    Django 1.8更改了其内部数据库结构，数据库中不再存在列name(请参见取自模型的详细名称属性)。

    为了解决这个问题，会自动创建一个迁移contenttypes到0002_remove_content_type_name。

    通常，您的所有迁移都应该应用，并且应该记录在表django_migrations中，并且所有迁移都应该是正常的。

    例如，如果您使用dump data备份了数据库，清除(刷新)了所有数据库内容，并使用loaddata加载了转储，那么您的django_migrations表将保持为空。

    因此，migrate尝试再次应用所有迁移(即使您的表已经存在)，并且当它尝试删除不存在的列name时失败。

    您可以通过检查您的django_migrations表来检查这种情况是否适用，或者通过运行python manage.py showmigrations更方便地检查这种情况。如果你的情况看起来像

    1
    2
    3
    contenttypes
     [X] 0001_initial
     [X] 0002_remove_content_type_name

    你很好(或者事实上你有一个不同的问题)，以防看起来像这样

    1
    2
    3
    contenttypes
     [ ] 0001_initial
     [ ] 0002_remove_content_type_name

    号

    你遇到了上述情况。请仔细检查数据库是否包含所有表和所有列(除了要在失败的迁移中应用的更改)。

    要做什么/逐步解决方案：

    因此，我们的数据库结构是正常的(除了您希望在失败的迁移中应用的更改)，但是Django/Migrate不知道这一点。所以让我们做点什么：

  • 告诉Django，所有内容类型迁移都已应用：manage.py migrate --fake contenttypes。如果您想再次检查，运行showmigrations。

  • 不要告诉Django，您要应用的迁移之前的所有迁移都已应用。为此，您需要迁移编号，如showmigrations所示。例如，如果你的情况看起来像

    1
    2
    3
    my_app
     [ ] 0001_initial
     [ ] 0002_auto_20160616_0713

    您的migrate在应用0002_auto_20160616_0713时失败，您数据库中最后一次成功应用迁移的是0001_initial。然后，Wen强制执行python manage.py migrate --fake my_app 0001在django_migrations表中的条目(记住迁移次数足够)。必要时，migrate将自动伪造所有其他依赖迁移。

  • 现在我们可以应用Missiong迁移了，这次我们要做的是真正的而不是伪造的！所以我们运行python manage.py migrate my_app。这将根据需要更改数据库。

    如果您的上一次迁移依赖于其他尚未被伪造的迁移，那么您应该事先伪造它们。

  • 复查和清理：再次使用showmigrations检查是否应用了所有迁移。如果存在开放式迁移，则使用python manage.py migrate --fake来伪造它们。

    • 你不应该做的事

    • 删除所有迁移—在生产设置中，这可能不适用，因为它们可能包含一些迁移不应丢失的数据的工作。
    • 手动将列name添加到contenttypes中-在应用迁移之后将删除该列。好吧，这是一个有效的黑客，但它不能解决问题。

      • 小精灵你应该做的事

      试着找出你是如何进入这种情况的，并找到避免这种情况的方法。

      我的问题是，我的项目有不同的数据库(用于快速开发测试的sqlite，用于真实世界测试的本地Postgres，用于生产的远程Postgres)，我想将内容从一个复制到另一个。

      相关讨论

      当升级到1.8并从mysql迁移到postgres时遇到了这个问题。

      我无法解释发生错误的原因，但我可以通过手动添加列来绕过它：

    • 删除所有迁移

    • 删除django_migrations中的记录

    • 手工添加name列：

      1
      ALTER TABLE django_content_type ADD COLUMN name character varying(50) NOT NULL DEFAULT 'someName';

    • 运行假首字母：$ python manage.py migrate --fake-initial

      • 编辑：2016年12月：我建议这是一个解决方案，更适合个人项目或本地环境，而不是生产环境。显然，如果你关心你的迁移历史，这不是一条路。

      相关讨论

      在我们决定从版本控制(Git)中删除迁移并从头创建新数据库之后，我遇到了这个错误。

      对我有用的东西(老实说，我不知道为什么)是为每个应用程序运行"makemigrations"。因此，对于每个django应用程序，"python manage.py makemigrations app1"、"python manage.py makemigrations app2"等。

      最后，我运行了"python manage.py migrate"，交叉手指，它工作了。

      了解这项工作的方式/原因会有所帮助。

      相关讨论

      我知道这是一个老问题，但这可能对某些人有所帮助。我也收到了这个错误。问题是内容类型有一个名为0002的迁移，即删除"名称"列的"内容类型名称"。
      从表和文件夹中删除迁移数据后，此步骤适用于我：

      1
      2
      3
      ./manage.py makemigrations myappname
      ./manage.py migrate myappname
      ./manage.py migrate --fake contenttypes

      号

      如果您确定数据库的其余部分反映了您的迁移，则可以使用：

      1
      ./manage.py migrate --fake

      结果如下：

      1
      ./manage.py showmigrations

      。

      在那之后，你所有的迁移都应该被标记，你应该很好

      相关讨论

      我有同样的问题，但是我可以通过将其添加到迁移依赖项中来解决它：

      1
      ('contenttypes', '0002_remove_content_type_name')

      。

      希望有帮助！

      另一个适用于我的变体(来自空白数据库)是：

      1
      2
      ./manage.py makemigrations myappname
      ./manage.py migrate

      一个不起作用的变体是：

      1
      2
      ./manage.py makemigrations myappname
      ./manage.py migrate myappname

      。

      或者，更确切地说，这一序列显然是第一次起作用，但第二次起作用却不起作用，因为当时人们抱怨django_content_type不存在。

      上面的工作变量(前两行)似乎是等幂的。

      (已编辑：从原来的3行工作版本中删除多余的第二行)