【问题标题】:Django returning FieldDoesNotExist error on server but passes fine in shellDjango 在服务器上返回 FieldDoesNotExist 错误,但在 shell 中通过正常
【发布时间】:2013-02-08 16:20:04
【问题描述】:

我正在尝试使用一组特定的 FK 字段来获取 ValuesQuerySet,这些字段跨越多个表之间的关系。当我在 django shell 中运行这个查询时,甚至没有打嗝。但是在开发服务器上运行它时,Django 在这些 FK 字段中的一些(但不是全部)上返回 FieldDoesNotExist 错误。

以下是相关模型(我使用的是标准 Django User 模型):

class Profile(models.Model):

    user = models.OneToOneField(User)
    first_name = models.CharField(max_length=150,null=True)
    middle_name = models.CharField(max_length=150,null=True)
    last_name = models.CharField(max_length=150,null=True)
    headline = models.TextField(null=True)
    connections = models.ManyToManyField('self',through="Connection",symmetrical=False,related_name="connections+")
    status = models.CharField(max_length=15,default="active")

class Position(models.Model):

    entity = models.ForeignKey(Entity,related_name="positions")
    person = models.ForeignKey(User,related_name="positions")
    careers = models.ManyToManyField("Career",related_name="positions")
    title = models.CharField(max_length=150,null=True)
    summary = models.CharField(max_length=450,null=True)
    description = models.TextField(null=True)
    current = models.BooleanField(default=True)
    start_date = models.DateField(null=True)
    end_date = models.DateField(null=True)
    type = models.CharField(max_length=450,null=True)
    degree = models.CharField(max_length=450,null=True)
    field = models.CharField(max_length=450,null=True)
    status = models.CharField(max_length=15,default="active")
    created = models.DateTimeField(auto_now_add=True, null=True)
    updated = models.DateTimeField(auto_now=True, null=True)

class Entity(models.Model):

    name = models.CharField(max_length=450)
    created = models.DateTimeField(auto_now_add=True)
    updated = models.DateTimeField(auto_now=True)
    status = models.CharField(max_length=15,default="active")

class Picture(models.Model):

    person = models.ForeignKey(Profile,related_name="pictures")
    pic = models.ImageField(max_length=450,upload_to=_get_picture_path)
    source = models.CharField(max_length=45,null=True)
    description = models.TextField(null=True)
    license = models.TextField(null=True)
    created = models.DateTimeField(auto_now_add=True)
    updated = models.DateTimeField(auto_now=True)
    status = models.CharField(max_length=15,default="active")

在一个视图中,我运行了两个略有不同的查询,以获取从这些连接的表中提取信息的用户切片(一个限制为一组用户 ID,user_ids):

some_people = User.objects.values('id','profile__headline','profile__first_name','profile__last_name','profile__pictures__pic','positions__entity__id','positions__entity__name').filter(id__in=user_ids).annotate(no_of_pos=Count('positions__id')).order_by('-no_of_pos')

all_people = User.objects.select_related('positions','profile').values('id','profile__headline','profile__first_name','profile__last_name','profile__pictures__pic','positions__entity__id','positions__entity__name').annotate(no_of_pos=Count('positions__id')).order_by('-no_of_pos')

这些功能几乎相同,一个仅限于一组预定义的用户(由 id 标识),另一个则不是。我知道这些结果会返回一些信息的重复项,但我会在后面的步骤中处理这些信息,将这些信息组合到稍微不同的模板字典中

如果我在 shell 中运行这些查询,就没有问题。查询不需要任何时间,并且所有字段都已正确评估。但是,开发服务器返回此错误:

User has no field named 'headline'

只要包含“profile_headline”、“profile_pictures_pic”、“positions_entity_name”,它就会返回类似的错误。这个错误对我没有任何意义。这些字段确实存在,但不存在于用户对象上——并且它们永远不会在用户对象上调用。另外,为什么只有这些字段? “profile_last_name”、“profile__first_name”和“positions_entity_id”在我看来应该都属于同一个 bin。

请帮我解决这个问题——有什么想法吗?

我在 Mac OS X 上运行 Django 1.4.2 和 Python 2.6。

【问题讨论】:

  • 你的数据库后端是什么?
  • 带有postgresql_psycopg2 后端的postgresql。只需删除并重新创建数据库并且没有修改模型。我也在使用South,但我不确定这是否会有所作为。
  • South 可能会影响一些东西。我正在尝试思考shell 环境和dev server 环境之间的区别。

标签: python django django-models python-2.6


【解决方案1】:

发生的情况是您在开发服务器上的模型定义与您拥有的物理数据库架构不匹配。可能是因为您添加了新字段但尚未迁移它们。

要检查,请运行./manage.py migrate --list。如果是这种情况,开发服务器上的迁移应该可以解决问题。

【讨论】:

  • shell 和开发服务器都在本地运行并使用相同的数据库。重新创建数据库后,我又完成了所有迁移,这并没有改变任何东西。
  • 在 psql shell 或 pgadmin 中,你真的看到表定义中的headline 字段了吗?
猜你喜欢
  • 2019-12-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-11-05
  • 1970-01-01
  • 1970-01-01
  • 2014-07-07
相关资源
最近更新 更多