django - 自定义用户类会破坏 django 中的应用程序吗？

Question

假设我已正确对用户模型 (CustomUser) 进行子类化(如下所述: http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/ )

并安装了评论应用程序。

访问我编写的模板中评论的用户:

{{comment.user}} # which provides User, not my CustomUser

因此，

{{comment.user.CustomProperty}} #does not work.

我该如何解决这个问题？

Answer 1

来自 comments.Comment 的 ForeignKey 是 django 内置的 User 对象，因此查询 comment.user 将为您提供父对象(即:基本 User 模型)。然而，django继承确实提供了一种从父类(super class)获取子类版本的方法:

{{ comment.user.customeruser }}

这将允许您执行以下操作:

{{ comment.user.customeruser.customproperty }}

我碰巧认为这是 Django 继承实现的一个弱点，因为它并不完全反射(reflect)您通常期望的 Python 中对象继承的行为，但至少有一个解决方法。因为我几乎不会急于提交具有我的正确行为版本的补丁，所以我不能提示:-)

<小时/>

我同意 Carl Meyer 的评论:在不更改父模型的数据库表的情况下自动获取子类可能会很昂贵，并且从父类查询返回子类的实例将与 Django 关于查询集返回模型的 promise 不一致运行查询集的位置。

然而，我在实践中仍然发现，Django 的继承有时会导致一些尴尬的额外步骤。从 0.91 开始使用 Django，并且知道解决对象关系映射问题的所有不同策略都需要权衡，我很高兴现在在 Django 中拥有继承，并且感觉当前的实现非常出色......所以我讨厌我原来的答案被理解为对该项目的轻微反对。

因此，我想我应该编辑这个答案以链接到卡尔本人在解决方案中提供的答案，以防您不知道子类是什么类型: How do I access the child classes of an object in Django without knowing the name of the child class? 。他在那里提供了使用 ContentType 框架的建议。仍然涉及一些间接，但在工具包中是一个很好的、可推广的选项。