Django database error: missing social_auth_usersocialauth table when social_auth is not set

I am trying to deal with a very cryptic error in a Django application. When DEBUG = False, an attempt to delete a user (via user.delete() ) gives this database error:

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

However, I don't have social_auth or anything like that in INSTALLED_APPS, and there are no such tables in my database, and none of my code links sorted anything like that (I ran a text search in 'social' in the entire project folder) - and again this works fine when DEBUG = True. social_auth is installed on my system and on my PYTHONPATH, but I don’t see how this application gets the idea that it should have social_auth tables in its database, not to mention why it only thinks when DEBUG = False.

What are some possible ways my application could get this table, and how can I convince it that it should not be there?

+6
source share
2 answers

The problem may be caused by persistent generic relationships implemented by Django content types . Relations in Django are not only static, implemented by models and INSTALLED_APPS , but also dynamically implemented by the django_content_type table, which preserves the mapping from the numeric id to app_label + model. An example of a possible dynamic relationship is resolution or comment. You may or may not have permission to any table in any installed application. You can write a comment on everything, for example, on an article, on the user of the comment itself without changing any model. This relationship is implemented by storing the numerical identifier ContentType associated with this model (table) and the primary key of the associated object (row).

Django does not expect anyone to manipulate the database manually. If you use south for manipulation, then if you run syncdb after uninstalling the application, you will be asked south if you want to automatically remove spelling types. You can then safely delete unused tables without further reference.

(Possible hack: delete from django_content_type where app_label='social_auth' , but south delete from django_content_type where app_label='social_auth' .)

Many parts of the question are still open.

Edit :
Why this was wrong: all generic relationships from descendants to parents, and all data about the relationship is stored in the descendant. If the child application is removed from INSTALLED_APPS, then the django.db code can never try to remove the descendants, because it cannot recognize which columns contain this relationship.

+1
source

This table is created by the django-social-auth application.

It looks like you added it to your project and did not run migrate (or syncdb ).

-1
source

All Articles