使用与内置关系相关的配置文件模型User
仍然是用于存储其他用户信息的完全合法的构造(在许多情况下建议使用)。鉴于内置的Django 1-to-1语法在此处干净利落地工作,因此现在不再使用的AUTH_PROFILE_MODULE
和get_profile()
东西变得不必要了。
如果您已经 则从旧用法的转换实际上很容易,这是建议在不赞成使用get_profile之前设置概要文件模块的方式。
class UserProfile(models.Model):
user = OneToOneField(User, related_name="profile")
# add profile fields here, e.g.,
nickname = CharField(...)
# usage: no get_profile() needed. Just standard 1-to-1 reverse Syntax!
nickname = request.user.profile.nickname
如果您不熟悉的语法,请参见此处OneToOneField
,这使这成为可能。最终可以轻松搜索并替换get_profile()
forprofile
或无论您related_name
是什么(在上述情况下,与汽车相关的名称都将是user_profile
)。标准的Django反向1-1语法实际上比get_profile()
!
但是,我意识到这并不能完全回答您的问题。您表示您在个人资料模块中使用了ForeignKey
toUser
,而不是使用OneToOne
,这很好,但是如果您将其保留为ForeignKey
,语法就不会那么简单,就像您在后续评论中所指出的那样。 假设您ForeignKey
在实践中将自己用作唯一的外键(本质上是一对一),因为在数据库中aOneToOneField
只是一个ForeignKey
带有unique=True
约束的字段,您应该能够在代码中而不用实际上必须进行大量的数据库迁移或导致任何数据丢失。
如果您使用 South 进行迁移,则执行上一节中的代码更改可能会使South误删除旧字段并创建新字段(如果您执行)schemamigration --auto
,因此您可能需要手动编辑迁移才能正确执行操作。一种方法是先创建schemamigration,然后取消前进和后退方法,这样它实际上就不会尝试做任何事情,但是仍然可以继续冻结模??型OneToOneField
。然后,如果您想做得完美,则还应该将唯一约束添加到相应的数据库外键列中。您既可以使用sql手动执行此操作,也可以通过South(通过手动编辑迁移方法或通过unique=True
在ForeignKey
并在将其切换为之前创建第一个South迁移,然后OneToOneField
进行第二个迁移,并取消掉前进/后退方法。