6

我正在尝试处理 Django 应用程序中一个非常令人费解的错误。当 DEBUG=False 时，尝试删除用户（通过user.delete()）会出现以下数据库错误：

DatabaseError: relation "social_auth_usersocialauth" does not exist
LINE 1: ...", "social_auth_usersocialauth"."extra_data" FROM "social_au...

但是，我在 INSTALLED_APPS 中没有 social_auth 或类似名称的任何东西，我的数据库中也没有任何这样的表，我的任何代码也没有引用任何类似的东西（我在整个 'social' 上运行了文本搜索项目文件夹） - 同样，当 DEBUG=True 时，这工作正常。social_auth 安装在我的系统和我的 PYTHONPATH 上，但我看不出这个应用程序从哪里得到它应该在其数据库中拥有 social_auth 表的想法，更不用说为什么它只在 DEBUG=False 时才这么认为。

我的应用程序可以从哪些可能的途径获取此表，我如何说服它不应该存在？

4

2 回答 2

1

该问题可能是由Django 内容类型实现的保存的通用关系引起的。Django 中的关系不仅是静态的，由模型实现，而且是动态的，由保存从数字 id 到 app_label + 模型的映射的表实现。可能的动态关系的一个示例是权限或评论。您可以拥有或不拥有任何已安装应用程序的任何表的权限。您可以在不更改任何模型的情况下对所有内容（例如文章、用户对评论本身）进行评论。这种关系是通过保存与该模型（表）相关的 ContentType 的数字 id 和相关对象（行）的主键来实现的。INSTALLED_APPSdjango_content_type

Django 不希望有人可以手动操作数据库。如果您使用south进行操作，那么如果您在卸载应用程序后运行syncdb，则 south 会询问您是否要自动删除孤立的内容类型。然后可以安全地删除未使用的表，而无需稍后引用。

（可能的黑客攻击：delete from django_content_type where app_label='social_auth'但south绝对可靠。）

问题的许多部分仍然悬而未决。

编辑：
为什么它不是正确的方法：所有通用关系都是从后代到父级，并且有关该关系的所有数据都保存在后代中。如果从 INSTALLED_APPS 中删除子应用程序，则 django.db 代码将永远无法尝试删除后代，因为它无法识别哪些列包含关系数据。

于 2012-11-14T22:34:39.500 回答
-1

此表由django-social-auth应用程序创建。

看起来您已将其添加到您的项目中并且尚未启动migrate（或syncdb）。

于 2012-11-13T19:25:36.863 回答