关系"django_content_type"的Django列"名称"不存在

Question

我在进行迁移时遇到以下错误(python manage.py migrate):

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

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

1. 我删除了每个模型的所有迁移文件
2. 删除了django_migrations中的所有记录
3. 运行python manage.py migrate --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

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

问题的根源:

Django 1.8更改了其内部数据库结构,并且该列name不再存在于数据库中(请参阅模型的verbose_name属性).

为了ADRESS此,迁移contenttypes- 0002_remove_content_type_name自动创建.

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

例如,如果您使用dumpdata备份数据库,清除(刷新)所有数据库内容,并使用loaddata加载转储,则django_migrations表格保持为空.

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

你可以通过检查你的django_migrations表来检查这种情况是否适用,或者 - 通过运行来更加方便python manage.py showmigrations.如果您的情况如此

contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name

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

contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name

你遇到了上述情况.请仔细检查,您的数据库包含所有表和所有列(除了您希望应用于失败的迁移的更改).

做什么/分步解决方案:

因此,我们的数据库结构是可以的(除了您希望应用于失败的迁移的更改),但Django/migrate只是不知道它.那么让我们来做一些事情:

1. 告诉Django,所有contenttypes迁移都已应用:manage.py migrate --fake contenttypes.如果要仔细检查,请运行showmigrations.

2. 不要告诉Django,已经应用了要应用的迁移之前的所有迁移.为此,您需要迁移号,如下所示showmigrations.例如,如果您的情况如此

   my_app
    [ ] 0001_initial
    [ ] 0002_auto_20160616_0713
   

   并且您migrate在申请时失败0002_auto_20160616_0713,您数据库中最后一次成功应用的迁移是0001_initial.然后,Wen执行django_migrations-table中的条目python manage.py migrate --fake my_app 0001(记住迁移的数量就足够了).migrate如有必要,将自动伪造所有其他依赖迁移.

3. 现在我们可以应用missiong迁移,这次我们必须真实而不是伪造!所以我们跑python manage.py migrate my_app.这应该根据需要改变数据库.

   如果您的上次迁移依赖于尚未伪造的其他迁移,则应事先伪造它们.

4. 仔细检查和清理:showmigrations再次使用以检查是否已应用所有迁移.如果有开放迁移,请使用伪造它们python manage.py migrate --fake.

你不应该做的事情

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

你应该做的事情

试着找出你是如何陷入这种情况并找到避免它的方法.

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

Answer 2

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

我无法解释为什么会发生错误,但我能够通过手动添加列来解决这个问题:

1. 删除所有迁移

2. 从中删除记录 django_migrations

3. 手动添加name列:

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

4. 运行假初始: $ python manage.py migrate --fake-initial

编辑12/2016:我建议将其作为一种解决方法,更适合个人项目或本地环境而非生产环境.显然,如果你关心你的迁移历史,那么这不是一条路.

Answer 3

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

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

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

./manage.py migrate --fake

查看结果：

./manage.py showmigrations

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

Answer 4

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

('contenttypes', '0002_remove_content_type_name')

希望能帮助到你！