Auth_user error with Django 1.8 and syncdb / migrate

Question

When upgrading to Django 1.8 (with zc.buildout) and running syncdb or porting, I get this message:

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

One of my models contains django.contrib.auth.models.User:

 user = models.ForeignKey( User, related_name='%(app_label)s_%(class)s_user', blank=True, null=True, editable=False ) 

Going to Django 1.7 removes the error. Should I include a User object in different ways in Django 1.8?

Answer 1

I will fix this by running auth first, then the rest of my migrations:

 python manage.py migrate auth python manage.py migrate 

Answer 2

In my environment, I fix this makemigrations run for all applications related to django.contrib.auth.models :

 manage.py makemigrations app_with_user_relation
 manage.py migrate

Answer 3

I also had the same problem that I decided to use it:

 python manage.py migrate auth python manage.py migrate 

Then migrate does its job

Answer 4

If you use a hero, how I was launched

 heroku run python manage.py makemigrations 

This will most likely give you a message that there are now changes. Ignore this, then run

 heroku run python manage.py migrate 

this will give you some result suggesting that something has been done. Finally run

 heroku run python manage.py createsuperuser 

Answer 5

This problem is contained in running "makemigrations" for all applications that have not yet been ported, that is, applications that do not yet have the file "initial_0001.py" in their migration directory.

This is done (in our case, we use the make file) by executing for each of these applications:

 manage.py makemigrations app_name 

Once this is done, you can do:

 manage.py migrate 

as usual.

The main reason for this is that for some reason

 manage.py makemigrations 

does not always create these initial migrations if they do not already exist. And this leads to the indicated error.

On the contrary

 manage.py makemigrations app_name 

always creates them (if they are not already). Unfortunately, I cannot understand the reasons for this asymmetry.

Answer 6

To fix this problem, here is what I did:

1) Find in your project all relationships with the foreign key, such as OneToOneField, ForeignKey and ManyToManyFields, including any reusable applications that reference auth.User or import the user and set him to settings.AUTH_USER_MODEL, as described above. With minimal use:

 'auth.User' 

2) For all models that have the above, make sure the models have a valid django migration (not south). If they have southern migrations, rename the directory to migrations_south, and then run the makemigrations command for this application:

 ./manage.py makemigrations affected_app 

Sometimes there is a django migration folder under a different name, rather than default migrations . In such cases, specify this via MIGRATION_MODULES in your .py settings:

 MIGRATION_MODULES = {'filer': 'filer.migrations_django'} 

Since the problem is difficult to find in larger projects, I commented on all user applications in INSTALLED_APPS in settings.py and ran a test command, as it will start the migration and try to recreate the database for you:

 ./manage.py test 

It looks like it fixed it for me. I'm not sure if step 1 is mandatory or just best practice. But you definitely need to convert applications to migration.

Hurrah!

PS. Get ready for what's coming in Django 1.9 . The syncdb command will be removed. The inherited method of synchronizing applications without migration is deleted, and migration is mandatory for all applications.

Answer 7

Try to contact the user with

 from django.conf import settings user = models.ForeignKey(settings.AUTH_USER_MODEL, related_name='%(app_label)s_%(class)s_user', blank=True, null=True, editable=False) 

Answer 8

I migrated the old Django 1.6 project to Django 1.8, and previously we used syncdb to migrate the database, and we did not take the initial migration steps for all the applications in our project. With Django 1.8, you will need working database migrations. Performance

 manage.py makemigrations <app_name> 

For all applications of our project our problems were fixed.

Answer 9

Perhaps you found the answer and solved the problem, but I would like to point out that in my case the above problem was solved by resetting the database and re-creating it with full user privileges. I was able to do this because I am working on a non-production environment, but doing this in an intermediate environment is not a good idea, so be careful.

Im using python 2.7.12 and the following specifications of my virtualenv:

 Django==1.10.5 django-crispy-forms==1.6.1 django-registration-redux==1.4 djangorestframework==3.5.3 olefile==0.44 packaging==16.8 Pillow==4.0.0 psycopg2==2.6.2