django 1.8 fails to django.db.utils.ProgrammingError: relation "auth_user" does not exist

Question

I had a working project with django 1.7, and now I moved it to django 1.8. I can do syncdb<\/code> and run the app with sqlite, but when I switch to postgres, it fails to do syncdb<\/strong> :

  Creating tables...
    Creating table x
    Creating table y
    Running deferred SQL...
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "~/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
    utility.execute()
  File "~/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "~/venv/lib/python2.7/site-packages/django/core/management/base.py", line 390, in run_from_argv
    self.execute(*args, **cmd_options)
  File "~/venv/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute
    output = self.handle(*args, **options)
  File "~/venv/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 25, in handle
    call_command("migrate", **options)
  File "~/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 120, in call_command
    return command.execute(*args, **defaults)
  File "~/venv/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute
    output = self.handle(*args, **options)
  File "~/venv/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 179, in handle
    created_models = self.sync_apps(connection, executor.loader.unmigrated_apps)
  File "~/venv/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 317, in sync_apps
    cursor.execute(statement)
  File "~/venv/lib/python2.7/site-packages/django/db/backends/utils.py", line 79, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "~/venv/lib/python2.7/site-packages/django/db/backends/utils.py", line 64, in execute
    return self.cursor.execute(sql, params)
  File "~/venv/lib/python2.7/site-packages/django/db/utils.py", line 97, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "~/venv/lib/python2.7/site-packages/django/db/backends/utils.py", line 62, in execute
    return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "auth_user" does not exist

Answer 1

I didn't like the idea of commenting/uncommenting code, so I tried a different approach: I migrated "manually" some apps, and then run django-admin.py migrate for the remaining ones. After deleting all the *.pyc files, my sequence of commands was:

$ django-admin.py migrate auth
$ django-admin.py migrate contentypes
$ django-admin.py migrate sites
$ django-admin.py migrate MY_CUSTOM_USER_APP
$ django-admin.py migrate

where MY_CUSTOM_USER_APP is the name of the application containing the model I set AUTH_USER_MODEL to in my settings file.

Hope it can help. Btw, it seems strange that the best way to synchronize your db in Django 1.8 is so complicated. I wonder if I'm missing something (I'm not very familiar with Django 1.8, I used to work with older versions)

Answer 2

Working on Django 1.10 I found out another solution: My application is named "web", and first I call:

python manage.py makemigrations web

then I call:

python manage.py makemigrations auth

then I call:

python manage.py migrate

Amazed: IT'S WORKING! :) It seems auth was searching for the AUTH_USER_MODEL "web.UserProfile" and a relation named web_user_profile, and it didn't find it, hence the error. On the other hand, calling makemigrations web first creates the required relation first, before auth is able to check and alert it's not there.

Answer 3

Always migrate db with python manage.py makemigrations and then python manage.py migrate in newer versions. For the error above if first time your are migrating your database then use python manage.py migrate --fake-initial . See docs https://docs.djangoproject.com/en/1.9/ref/django-admin/#django-admin-migrate

Answer 4

I had the same problem, and I spent hours banging my head trying to find a solution, which was hidden in the comments. My problem was that CircleCI couldn't run tests because of this error. And I thought I would need to start fresh with a new and empty DB. But I got the same errors. Everything was seemingly related to 'auth', 'contenttypes' and 'sites'.

I read this , and this , as well as this and also this . None were solutions for me.

So after having destroyed my DB and created a new one, the only solution I found to entirely avoid these django.db.utils.ProgrammingError was to:

1. Comment out all code related to the User model.
2. Delete all .pyc files in my project! find . -name "*.pyc" -exec rm -- {} + find . -name "*.pyc" -exec rm -- {} + Thanks @max!
3. run ./manage.py migrate (no fake, no fake-initial, no migration of 'auth' or 'contenttypes' before, juste plain migrate.
4. Uncomment the above code, and run migrate again!

My INSTALLED_APP is the following:

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.contenttypes',
    'django.contrib.sites',
    'django.contrib.auth',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
    'mptt',
    'djangobower',
    'honeypot',
    'django_hosts',
    'leaflet',
    'multiselectfield',
    'corsheaders',
    'rest_framework_swagger',
    'allauth',
    'allauth.account',
    # 'allauth.socialaccount',
    # 'allauth.socialaccount.providers.twitter',
    # 'allauth.socialaccount.providers.facebook',
    'project.<app_name>',
)

Answer 5

Deleting migration files, associated .pyc files, and just to be safe all .pyc files with the following commands did not solve my issue.

$ find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
$ find . -path "*/migrations/*.pyc"  -delete
$ find . -name "*.pyc" -exec rm -- {} +

What ended up solving my issue wasn't clearing caches, it was because I had a function that performed a query as a default function parameter. On init, which is what commands like makemigrations and migrate do before executing it seems like django (perhaps a python attribute?) initializes all default parameters.

As my database was completely empty (I needed to perform migrate --run-syncdb to recreate the tables) when the below default parameter was initialized, it ran a query against the empty database that subsequently failed.

change this:

def generate_new_addresses(number=1, index=None, wallet=get_active_wallet()):
   ...
   ...
   return

to:

def generate_new_addresses(number=1, index=None, wallet=None):
   if not wallet:
      wallet = get_active_wallet()
   ...
   ...
   return

Answer 6

In my case, this error was appearing when the postgresql driver was able to connect to the database, but the provided user does not have access to the schema or the tables, etc. Instead of saying permission denied, the error being shown is saying that the database table being queried is not being found. Typically in such a situation, the migrate command will also fail with a similar error when it tries to create the django_migrations table.

Check for access being granted on the user you're using in database connection in Django.

Answer 7

I had the same issue, but my underlying cause was the __init__.py file in one of the migrations folders had been deleted from source code but not locally (causing 'Not on my machine' errors).

Migrations folders still need __init__.py files, even with Python 3.

Answer 8

I had this issues with a forms.ChoiceForm queryset. I was able to switch to using forms.ModelChoiceForm which are lazily evaluated and this fixed the problem for me.

Answer 9

In My Case I made migrations using some other similar looking migration file(1). Then I deleted it, and made 2 new migration files for replacement(2&3). And then I was getting this error.

In my case the table was renamed using migration file 1 But django was searching for old table name in migration file 3

So I renamed table manually to old name, and applied migration and It was successful

Answer 10

Error is basically because db (postgres or sqlite) have not found the relation, for which you are inserting or else performing CRUD. The solution is to make migrations

python manage.py makemigrations <app_name> python manage.py migrate