python - Django: relation "django_site" does not exist

Question

I am running a test django server on aws and I just installed django-userena and when I try to signup a user upon clicking submit, I get the following message:

relation "django_site" does not exist LINE 1: ..."django_site"."domain", "django_site"."name" FROM "django_si...

I am not really sure what went wrong here. I did some researching and added " 'django.contrib.sites'," to my installed apps, but I am still getting the error. I will there is an extra step I am missing. Any suggestions or advice?

Answer 1

I recently ran into this issue (Django 1.8.7) even with SITE_ID = 1 in my settings. I had to manually migrate the sites app before any other migrations:

./manage.py migrate sites
./manage.py migrate

Answer 2

You may be calling a site object before creating site model(before syncdb or migrate)

ex: site = Site.objects.get(id=settings.SITE_ID)

Answer 3

I have the same problem and fixed it like this:

1. add SITE_ID=1 into settings.py

2. run this command :

   python manage.py migrate
   

Answer 4

A horrible code lead to this error for me. I had a global variable to get the current site

SITE = Site.objects.get(pk=1)

this was evaluated during migration and lead to the error.

Answer 5

This issue might be caused by one of the apps you're using. If you check the traceback carefully, you might already find the delinquent.

I had those issues using django-debug-toolbarand zinnia.

If you are using the django-debug-toolbar this might be a solution:

Try following the steps for the explicit setup: http://django-debug-toolbar.readthedocs.org/en/1.2.2/installation.html#explicit-setup

Alternatively remove debug_toolbar from your INSTALLED APPS.

If that doesn't help or if another app is causing the issue, try to temporarily remove all imports (e.g. installed app, urls, custom views, settings), which are displayed in the traceback.

Answer 6

Going to leave this here for future me:

python manage.py makemigrations allauth

This worked for me, I forgot why, took me too long to figure out how I fixed this the first time

Edit: makemigrations sometimes doesnt make 3rd party things like allauth which some of my projects use, so I have to specify those ones

Answer 7

I experienced the same problem with creating a new empty database for my project (which uses zinnia)

Running 'manage migrate site' before 'manage migrate' did not solve anything. It seems that the complete project was loaded before any table creating was done.

I resolved to catching the errors that importing the zinnia releated app produced.

e.g.: in the urls.py of the app

urlpatterns = None
app_name = 'something'

try:
    from .views import MyEntryCreate


    urlpatterns = [

    url(r'^blogentry/create/$',
        login_required(MyEntryCreate.as_view()),
        name='zinnia_entry-add'),

    ]
except Exception as e:
    logger.error(app_name+" Error urls: "+str(e))
    urlpatterns = []

Had to do something like that elsewhere in that app, and 'manage migrate' worked again.

Answer 8

if you are getting this error when deploying you django app to Heroku, make sure you have run:

heroku run python manage.py migrate

This worked for me

Answer 9

I got this error while working with django-cookiecutter, django-allauth and django-rest-auth

I literally spent 5 hours pulling my hair out. Eventually gave in and started to comment out bit by bit

What worked for me was commenting out both pre-configured url paths (they come with cookiecutter Django):

# User management
path("users/", include("yourapp.users.urls")),
path("accounts/", include("allauth.urls")),

After that migrations worked.

I uncommented it and my app has worked ever since. It was only for the initial migration

Hope it helps someone!

Answer 10

I'm late, but I ran into the same issue with django v 1.11.

The issue was that I was rebuilding a model outside the normal def() and in a form() [I use the models for a choice] The traceback should have the .py file listed

e.g.

 File "filepath/views.py", line 67, in <module>
    some_variable = some_model.objects.get(name ='name')

So I had to comment it out to rebuild my migrations