在 Django 中，如何更改 User 类以使用不同的数据库表？
我们与现有应用程序一起运行 django，并与之共享数据库。 我们希望使用现有的“用户”表（不是 Django 自己的）来存储用户信息。
看起来可以在 User 定义的 Meta 类中更改 Django 使用的表的名称。
但我们不想改变 Django 核心本身。
所以我们认为我们可以像这样子类化核心 auth.User 类：
class OurUser(User) :
objects = UserManager()
class Meta:
db_table = u'our_user_table'
这里的目标不是向自定义 User 类添加任何额外的字段。 但只是使用替代表。
然而，这会失败（可能是因为 ORM 假设 our_user_table 应该有一个外键引用原始 User 表，但事实并非如此）。
那么，这是做我们想做的事情的明智方法吗？ 我是否错过了一些将类映射到表的更简单的方法？ 或者，如果没有的话，可以让它发挥作用吗？
更新：
我想我也许可以通过在 local_settings.py 中“猴子修补”用户的 _meta 来进行我想要的更改。
User._meta.db_table = 'our_user_table'
有人能想到如果我这样做会发生什么不好的事情吗？ （特别是在相当典型的 Django / Pinax 应用程序的上下文中？）
We're running django alongside - and sharing a database with - an existing application. And we want to use an existing "user" table (not Django's own) to store user information.
It looks like it's possible to change the name of the table that Django uses, in the Meta class of the User definition.
But we'd prefer not to change the Django core itself.
So we were thinking that we could sub-class the core auth.User class like this :
class OurUser(User) :
objects = UserManager()
class Meta:
db_table = u'our_user_table'
Here, the aim is not to add any extra fields to the customized User class. But just to use the alternative table.
However, this fails (likely because the ORM is assuming that the our_user_table should have a foreign key referring back to the original User table, which it doesn't).
So, is this sensible way to do what we want to do? Have I missed out on some easier way to map classes onto tables? Or, if not, can this be made to work?
Update :
I think I might be able to make the change I want just by "monkey-patching" the _meta of User in a local_settings.py
User._meta.db_table = 'our_user_table'
Can anyone think of anything bad that could happen if I do this? (Particularly in the context of a fairly typical Django / Pinax application?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能会发现将旧表设置为 很有用替代身份验证源并回避所有这些问题。
另一种选择是对用户进行子类化 并使子类指向您的用户模型。 覆盖保存功能以确保保留旧功能所需的一切都在那里。
我自己还没有做过这些，但希望它们是有用的指导。
更新
在这种情况下，我所说的替代身份验证是一个小的 python 脚本，它显示“是的，这是一个有效的用户名/密码”——然后它在标准 Django 表中创建一个模型实例，从旧表复制字段并返回新用户给呼叫者。
如果您需要保持两个表同步，您可以决定让您的替代身份验证永远不会创建标准 django 用户，只需说“是的，这是有效的密码和用户名”
You might find it useful to set up your old table as an alternative authentication source and sidestep all these issues.
Another option is to subclass the user and have the subclass point to your user-model. Override the save function to ensure that everything you need to do to preserve your old functionality is there.
I haven't done either of these myself but hopefully they are useful pointers.
Update
What I mean by alternative authentication in this case is a small python script that says "Yes, this is a valid username / password" - It then creates an instance of model in the standard Django table, copies fields across from the legacy table and returns the new user to the caller.
If you need to keep the two tables in sync, you could decide to have your alternative authentication never create a standard django user and just say "Yes, this is a valid password and username"