关系 "django_content_type" 的 Django 列 "name" 不存在

Question

我在执行迁移（python manage.py 迁移时不断收到以下错误：

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

我已经做了以下尝试修复它但没有成功：

我已经删除了每个模型的所有迁移文件
删除了django_migrations
运行 python manage.py 迁移 --fake-initial

运行 Django 1.8.2.

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

感谢您的帮助。

Answer 1

升级到 1.8 并从 MySQL 迁移到 Postgres 时遇到此问题。

我无法解释为什么会出现错误，但我可以通过手动添加列来解决这个问题：

删除所有迁移
从 django_migrations

手动添加name列：

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

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

编辑 12/2016：我建议将此作为解决方法，更适合个人项目或本地环境，而不适合生产环境。显然，如果您关心自己的迁移历史，那么这不是正确的选择。

Answer 2

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

对我有用的东西（虽然老实说我不确定为什么）是每个应用程序运行 'makemigrations'。因此，'python manage.py makemigrations app1'、'python manage.py makemigrations app2'，每个 Django 应用程序依此类推。

最后，我只是运行 'python manage.py migrate'，祈祷成功了。

任何对 how/why 这行得通的见解都会有所帮助。

Answer 3

我知道这是一个老问题，但这可能对某些人有所帮助。我也遇到了这个错误。问题是 content_types 有一个名为 0002_remove_content_type_name 的迁移删除了列 "name".
从 table 和文件夹中删除迁移数据后，此步骤适用于我：

./manage.py makemigrations myappname
./manage.py migrate myappname
./manage.py migrate --fake contenttypes

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

./manage.py migrate --fake

查看结果：

./manage.py showmigrations

在那之后，你所有的迁移都应该被标记，你应该没问题

Answer 4

我运行今天遇到了同样的问题，我想补充一下问题的总结和解决方法：

问题来源：

Django 1.8 更改了其内部数据库结构，数据库中不再存在列 name（请参阅 is taken from the verbose_name attribute of the model）。

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

通常，您的所有迁移都应该已经应用，这应该记录在 table django_migrations 中，一切都应该没问题。

例如，如果您使用 dumpdata 备份了数据库，清除（刷新）了所有数据库内容，并使用 loaddata 加载了转储，则您的 django_migrations table 仍然是空的。

因此，migrate 尝试再次应用所有迁移（即使您的 table 已存在），但在尝试删除不存在的列时失败 name .

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

contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name

你很好（或者实际上你遇到了不同的问题），以防它看起来像这样

contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name

你运行进入了上述情况。请仔细检查，您的数据库是否包含所有 table 和所有列（除了您希望在失败的迁移中应用的更改）。

怎么办/分步解决方案：

所以我们的数据库结构没问题（除了你想在失败的迁移中应用的更改），但 Django / migrate 不知道它。所以让我们做点什么：

告诉 Django，已应用所有内容类型迁移：
manage.py migrate --fake contenttypes
如果你想仔细检查，运行 showmigrations.
现在让我们告诉 Django 您要应用的迁移之前的所有迁移都已应用。为此，您需要 showmigrations 所示的迁移编号。例如，如果您的情况看起来像
```
my_app
 [ ] 0001_initial
 [ ] 0002_auto_20160616_0713
```
并且您的 migrate 在应用 0002_auto_20160616_0713 时失败，您数据库中最后一次成功应用的迁移是 0001_initial。然后，我们通过
强制执行 django_migrations-table 中的条目 python manage.py migrate --fake my_app 0001
（记住迁移的数量是足够的）。 migrate 将在必要时自动伪造所有其他依赖迁移。
现在可以申请missiong迁移了，这次一定要真人真事，不能做假！所以我们运行python manage.py migrate my_app。这应该根据需要更改数据库。

如果您的最后一次迁移依赖于其他尚未伪造的迁移，您应该事先伪造它们。
双重检查和清理：再次使用 showmigrations 检查是否已应用所有迁移。如果有开放迁移，请使用 python manage.py migrate --fake.
伪造它们

你应该不做的事情

删除所有迁移 - 在生产环境中这可能不适用，因为它们可能包含一些不应丢失的迁移数据工作。
手动将列 name 添加到 contenttypes - 应用迁移后它将被删除。好的，这是一个可行的 hack，但它没有解决问题。

你应该做的事情

试着弄清楚你是如何陷入这种情况并找到避免它的方法。

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

Answer 5

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

('contenttypes', '0002_remove_content_type_name')

希望对您有所帮助！

Answer 6

另一个对我有用的变体（来自空白数据库）是：

./manage.py makemigrations myappname
./manage.py migrate

一个无效的变体是：

./manage.py makemigrations myappname
./manage.py migrate myappname

或者更确切地说，该序列第一次显然有效，但第二次无效，然后抱怨 django_content_type 不存在。

上面的工作（第一个 2 行）变体似乎是幂等的。

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

Answer 7

对我来说，我运行 makemigrations 我的每个 INSTALLED_APPS 使用这个命令：

python manage.py makemigrations compressor

用您的 INSTALLED_APPS 更换压缩器。然后使用此命令成功迁移：

python manage.py migrate

Answer 8

您的某些代码试图访问 django_content_type table，但它不存在，导致 ProgrammingError。一个工作轮是将该部分包装在 try except 中。样本

try:
    seller_content_type = ContentType.objects.get_for_model(Seller)
    add_seller_permission = Permission.objects.get(
        codename='add_seller',
        content_type=seller_content_type,
    )
except ProgrammingError:
    add_seller_permission = None

您实际上可以将 add_seller_permission = None 替换为 pass，但如果您在其他地方使用该值，以上内容会有所帮助，因此它至少在迁移完成之前仍然可用。

Answer 9

好吧 None 这实际上对我有用所以我只是在 postgresql 中删除了我的数据库并创建了一个新的然后运行删除了我以前的迁移文件夹最后做了所有的迁移和一切正常

Answer 10

我遇到了类似的问题。我最终成为这个职位的方式与其他人一样，我将数据库从一台服务器移动到另一台服务器。发生的事情是我试图通过删除所有迁移文件来修复失败的迁移。这真正做的是删除 0002_remove_content_type_name.py 文件，这就是整个问题对我来说开始的地方。

此文件位于 \venv\Lib\site-packages\django\contrib\contenttypes\migrations 文件夹中。因此它与您的虚拟环境相关联。我复制数据库的服务器有它自己的虚拟环境（从未复制过）所以它仍然在文件夹中有 0002_remove_content_type_name.py 文件。

对于 django 来说，这看起来像是一个未应用的迁移。而且由于我抓取了我的迁移 table 和我测试服务器中的所有迁移文件，它总是在我的生产服务器上寻找该迁移。

我如何解决这个问题是将 0002_remove_content_type_name.py 从我的生产服务器复制回我的测试服务器和运行假迁移。所以现在每次我将测试数据库复制到产品时，都不会发生这种情况。

我也非常不建议像我现在那样复制数据库，因为这首先让我陷入了所有这些麻烦。

如果我没有此文件的副本，我的完整解决方案如下：

创建新的虚拟环境
从头开始创建一个测试 django 项目
将新创建的虚拟环境中的 0002_remove_content_type_name.py 复制到我当前项目中的相同位置(\venv\Lib\site-packages\django\contrib\contenttypes\migrations)
运行 "python manage.py showmigrations" 以确保它现在已列出
运行 "python manage.py contenttypes --fake

现在所有未来的迁移都应该可以正常工作，因为它将再次列在迁移 table 中。

注意：如果您对 Auth 和 Admin 有同样的问题，请对文件执行相同的操作。它们位于虚拟环境中各自的文件夹中。我相信管理员总共有 3 个迁移，而 auth 有 11 个。我注意到在我解决了我的内容类型问题后这些都消失了。

Answer 11

我在 Django 3.2 项目中遇到这个错误，而运行ning makemigrations (and/or migrate) 在新数据库上。在这种情况下，问题是我有一行运行ning on import （例如，在模块或 class 级别）访问了 ContentTypes，像这样：

TERM_CONTENT_TYPE = ContentType.objects.get_for_model(Term)

由于导入过程中没有创建数据库，所以总是失败并出现上述错误。

这种情况下的解决方案是将任何类似的数据库交互移动到导入过程中不会运行的方法或其他地方。

关系 "django_content_type" 的 Django 列 "name" 不存在

Django column "name" of relation "django_content_type" does not exist

django

django-models

问题来源：

怎么办/分步解决方案：

你应该不做的事情

你应该做的事情