postgresql Django 迁移错误：列不存在

Django Migration Error: Column does not exist

提问by Alex

Python 3, Django 1.8.5, Postgres

Python 3、Django 1.8.5、Postgres

I have a model Sitesthat has been working fine. I recently tried to add a field, airport_code, and migrate the data.

我有一个Sites运行良好的模型。我最近尝试添加一个字段，airport_code，并迁移数据。

class Site(BaseModel):

  objects = SiteManager()

  name = models.CharField(max_length=200, unique=True)
  domain = models.CharField(max_length=200, unique=True)
  weather = models.CharField(max_length=10)
  nearby_sites = models.ManyToManyField('self', symmetrical=False, blank=True)
  users = models.ManyToManyField(settings.AUTH_USER_MODEL, blank=True)
  facebook = models.URLField(max_length=200)
  twitter = models.URLField(max_length=200)
  header_override = models.TextField(blank=True)
  email_header_override = models.TextField(blank=True)
  timely_site_tag_id = models.IntegerField()
  timely_featured_tag_id = models.IntegerField()
  timely_domain = models.CharField(max_length=255)
  sitemap_public_id = models.CharField(max_length=255)
  state = models.CharField(max_length=24)
  airport_code = JSONField()

However, when I ran makemigrationsI got an error:

但是，当我运行时makemigrations出现错误：

django.db.utils.ProgrammingError: column sites_site.airport_code does not exist LINE 1: ..._site"."sitemap_public_id", "sites_site"."state", "sites_sit...

django.db.utils.ProgrammingError: column sites_site.airport_code does not exist LINE 1: ..._site"."sitemap_public_id", "sites_site"."state", "sites_sit...

Of course, this doesn't make sense, because the column obviously does not exist when I'm trying to create it within the migration.

当然，这没有意义，因为当我尝试在迁移中创建该列时，该列显然不存在。

I have seen many questions about this bug on Stack Overflow that are unanswered, or have a solution to manually create the migration file, or destroy and rebuild the database. This is not an okay solution.

我在 Stack Overflow 上看到很多关于这个 bug 的问题都没有得到解答，或者有手动创建迁移文件的解决方案，或者销毁和重建数据库。这不是一个好的解决方案。

采纳答案by Alex

This bug was resolved for me by commenting out the django debug toolbar from INSTALLED_APPS in settings.py. I am not sure why debug toolbar is the culprit, but after I commented it out, I was able to run makemigrationsand migratewith no issue.

通过在 settings.py 中注释掉 INSTALLED_APPS 中的 django 调试工具栏，我解决了这个错误。我不确定为什么调试工具栏是罪魁祸首，但在我将其注释掉后，我能够运行makemigrations并且migrate没有问题。

Hoping this helps someone, as I spent twelve hours trying to figure it out.

希望这对某人有所帮助，因为我花了十二个小时试图弄清楚。

回答by Nexus

After you run makemigrations, be sure to go through the stack trace step by step.

运行 makemigrations 后，请确保逐步完成堆栈跟踪。

In my case, I noticed it traced through a call to a Form contained within a forms.py in a completely different app, which happened to have a call to the model I was trying to create a new migration for.

就我而言，我注意到它是通过调用一个完全不同的应用程序中包含在 forms.py 中的表单来跟踪的，这恰好调用了我试图为其创建新迁移的模型。

Moving the Form class out of forms.py into the views.py fixed the issue.

将 Form 类从 forms.py 移到 views.py 中解决了该问题。

回答by darksider

In my case, that was because I had a unique_together constraint that was set.

就我而言，那是因为我设置了一个 unique_together 约束。

When I wanted to remove a field, the auto-generated migration tried to remove the field before removing the unique_together constraint.

当我想删除一个字段时，自动生成的迁移尝试在删除 unique_together 约束之前删除该字段。

What I had to do was manually move up the migrations.AlterUniqueTogether constraint in the migration file, so that django removes first the constraint before trying to remove the field.

我必须做的是手动向上移动迁移文件中的 migrations.AlterUniqueTogether 约束，以便 django 在尝试删除字段之前先删除约束。

I hope this can help someone.

我希望这可以帮助某人。

回答by theeastcoastwest

I ran into this issue as well and the answer by @Nexus helped. I thought I'd provide details of my specific case here for better illustrate the cause of the issue. It seems like a potential bug to me.

我也遇到了这个问题，@Nexus 的回答有所帮助。我想我会在这里提供我的具体案例的详细信息，以便更好地说明问题的原因。这对我来说似乎是一个潜在的错误。

I have a model Brandas follows:

我有一个模型Brand如下：

class Brand(BaseModelClass):
    name = CharField(max_length=256, unique=True)
    website = ForeignKey(URL, on_delete=CASCADE, null=True, blank=True)

I was running a python manage.py makemigrationsafter adding a Booleanfield as follows:

python manage.py makemigrations添加Boolean字段后我正在运行，如下所示：

class Brand(BaseModelClass):
    name = CharField(max_length=256, unique=True)
    website = ForeignKey(URL, on_delete=CASCADE, null=True, blank=True)
    trusted = Boolean(default=True)

When running the makemigrationscommand, I recieved an error similar to OP's:

运行makemigrations命令时，我收到类似于 OP 的错误：

django.db.utils.ProgrammingError: column appname_brand.trusted does not exist

Per @Nexus' suggestion, I went through the stacktrace, line-by-line, assuming that it wasn't some core issue with Django. As it turns out, in one of apps forms.pyfile I had the following:

根据@Nexus 的建议，我逐行浏览了堆栈跟踪，假设这不是 Django 的一些核心问题。事实证明，在其中一个应用程序forms.py文件中，我有以下内容：

choices={(str(brand.id), brand.name) for brand in Brand.objects.all()}

The solution was to simply comment-out that line, run manage.py makemigrations, then run manage.py migrate. Afterwards, I uncommented the line and everything and my forms' functionality worked just as before.

解决方案是简单地注释掉该行， run manage.py makemigrations，然后 run manage.py migrate。之后，我取消了该行的注释，所有内容和表单的功能都像以前一样工作。

回答by nveo

Make sure you are not doing any queries when loading the application!, as eg. in:

确保您在加载应用程序时没有进行任何查询！，例如。在：

class A:
  field = fn_that_makes_query()

When running migrateor makemigrations, Django performs system checks, which loads the entire application, so if during this process any queries are made which use added/altered db fields you run into inconsitencies, because you are trying to access db fileds that are not there yet.

在运行migrateor 时makemigrations，Django 执行系统检查，这会加载整个应用程序，因此如果在此过程中进行了任何使用添加/更改的 db 字段的查询，您会遇到不一致的情况，因为您正在尝试访问尚不存在的 db 字段。

回答by Cat_S

I got the same issue, here is my case: in the app MyAppI add a new field to the model:

我遇到了同样的问题，这是我的情况：在应用程序中，MyApp我向模型添加了一个新字段：

class Advisors(models.Model):
    AdvID = models.IntegerField(primary_key=True)
    Name = models.CharField(max_length=200,null=False)
    ParentID = models.IntegerField(null=True) # <--- the NEW field I add

so what I did is: in the urls.pyof MyProject, NOT MyApp, comment out the url() linked to MyAppand then do makemigrationsand migrateeverything goes well; in MyApp/urls.pyfile:

所以我所做的是：在urls.pyof MyProject, NOT 中MyApp，注释掉链接到的 url() MyApp，然后执行makemigrations，migrate一切顺利；在MyApp/urls.py文件中：

urlpatterns = [
    url(r'^admin/', admin.site.urls, name='admin'),
    url(r'^$', views.HomePage.as_view(),name='home'),
    #comment out the following line, after migrate success, bring it back;
    # url(r'^myapp/', include('myapp.urls',namespace='research')), <--- 
]

回答by santhosh_dj

I too got same issue when i executed a cmd like python manage.py makemigrations app1. I resolved my issue by commenting the custom orms which is running in another app2 under views.

当我执行像 .cmd 这样的 cmd 时，我也遇到了同样的问题python manage.py makemigrations app1。我通过评论在视图下的另一个 app2 中运行的自定义 orms 解决了我的问题。

Example:

例子：

inside app1models.py

在 app1models.py里面

class ModelA(models.Model):
    subject = models.CharField(max_length=1)
    course = models.CharField(max_length=1)

inside app2view.py

在 app2view.py里面

# obj = ModelA.object.all()
# get_subjct = [s.subject for s in obj]

So here i have commented above code and executed the makemigrations and migrate then uncommented.

所以在这里我已经注释了上面的代码并执行了 makemigrations 和 migrate 然后取消注释。

Working fine...

工作正常...

回答by Pantone877

Late to the party, but there is some info I want to share. It helped me a lot! :)

聚会迟到了，但我想分享一些信息。这对我帮助很大！:)

I am using django-soloto store app config in database, and I got the same issue as Alex when adding new field to configuration model. Stacktrace pointed me to the line where I'm getting config from database: conf = SiteConfiguration().get_solo().

我正在使用django-solo将应用程序配置存储在数据库中，并且在向配置模型添加新字段时遇到了与 Alex 相同的问题。堆栈跟踪指着我的地方，我正从数据库配置行：conf = SiteConfiguration().get_solo()。

There is a closed issuefor django-solo project on Github. The idea is to make model loading lazy (exactly as MrKickkiller pointed before).

Github 上的 django-solo 项目有一个已关闭的问题。这个想法是使模型加载延迟（正如 MrKickkiller 之前指出的那样）。

So for modern Django version (in my case 3.0) this code works perfectly:

因此，对于现代 Django 版本（在我的情况下为 3.0），此代码完美运行：

from django.utils.functional import SimpleLazyObject
conf = SimpleLazyObject(SiteConfiguration.get_solo)

回答by Jeff Bauer

I ran into this problem recently after upgrading to Django 1.11. I wanted to permanently address the issue so I wouldn't have to comment / uncomment code every time I ran a migration on the table, so my approach:

我最近在升级到 Django 1.11 后遇到了这个问题。我想永久解决这个问题，这样我就不必每次在表上运行迁移时都注释/取消注释代码，所以我的方法是：

from django.db.utils import ProgrammingError as AvoidDataMigrationError

try:
    ... do stuff that breaks migrations
except AvoidDataMigrationError:
    pass

I rename the exception during import to AvoidDataMigrationErrorso it's clear why it's there.

我在导入过程中将异常重命名为，AvoidDataMigrationError以便清楚为什么它在那里。

回答by MrKickkiller

Just now had the same error when I tried to migrate a SingletonModel to actually contain the necessary fields.

刚才在我尝试迁移 SingletonModel 以实际包含必要字段时遇到了同样的错误。

Reason for the error was that my Model A used some fields of this SingletonModel (as configurable values). And during instantation of model A during the migration process it obviously couldn't guarantee that my migration was safe.

错误的原因是我的模型 A 使用了这个 SingletonModel 的一些字段（作为可配置值）。在迁移过程中模型 A 的实例化期间，它显然不能保证我的迁移是安全的。

A colleague had a wonderful idea. Make the default value for the field a function call, and therefor lazy.

一位同事想到了一个绝妙的主意。将该字段的默认值设为函数调用，因此是惰性的。

Example:

例子：

class A (models.Model):
    default_value = models.DecimalField(default: lambda: SingletonModel.get_solo().value, ...)

So therefor, my advice: Try and make the offending call (seen in stacktrace) a lazy one.

因此，我的建议是：尝试使有问题的调用（在堆栈跟踪中看到）变成一个懒惰的调用。