Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Django 1.8b1: relation "auth_user" does not exist #204

Closed
ivasic opened this issue Mar 9, 2015 · 6 comments
Closed

Django 1.8b1: relation "auth_user" does not exist #204

ivasic opened this issue Mar 9, 2015 · 6 comments

Comments

@ivasic
Copy link

ivasic commented Mar 9, 2015

Seems that something is bothering Django 1.8b1 when applying migrations on PostgreSQL, even on a fresh django project without any apps (or any fancy stuff with custom models). Just create a new django project, add oauth2_provider to the installed apps and run "python manage.py test" to trigger it.

I've created a simple project that reproduces it here: http://cl.ly/3e1b0B1g0n2J (make sure you create a PostgreSQL db as per settings.py)

I should note that when I remove oauth2_provider from my installed apps, do the first migration (so that the auth_user table is created), put it back in installed apps and do another migration - then it works fine since auth_user table is created beforehand. Running tests, however, creates everything at once so it always triggers this problem and I'm unable to run any tests.

Environment: Django 1.8b1, django-oauth-toolkit 0.7.2, Python 3.4

Anyone knows if this is a Django 1.8 problem perhaps?

@chrisguitarguy
Copy link

This doesn't happen with Django 1.7.

manage.py test runs the migrate command, which fails with the same error:

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

From what I can tell, this happening because the syncdb Stuff, which creates the models for this library, runs before the migrations. The docs warn against this: https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies

Be aware, however, that unmigrated apps cannot depend on migrated apps, by the very nature of not having migrations. This means that it is not generally possible to have an unmigrated app have a ForeignKey or ManyToManyField to a migrated app; some cases may work, but it will eventually fail.

But there's a way around it!

As time goes on, more and more third-party apps will get migrations, but in the meantime you can either give them migrations yourself (using MIGRATION_MODULES to store those modules outside of the app’s own module if you wish), [...]

So in your settings, you can add something like this:

# makemigrations requires this for some reason or it errors
# Just set to the default value
OAUTH2_PROVIDER_APPLICATION_MODEL = 'oauth2_provider.Application'

# tell django where to put the oauth2 migrations
MIGRATION_MODULES = {
   # key: app name, value: a fully qualified package name, not the usual `app_label.something_else`
  'oauth2_provider': 'yourproject.migrations.oauth2_provider',
}

Then run ./manage.py makemigrations oauth2_provider to generate a new migration for this app.

Long term the solution seems to be migrating to django's internal migration system. I've not used south before, so not sure how much of a pain that is.

@ivasic
Copy link
Author

ivasic commented Mar 10, 2015

Thanks Christopher, this worked great. Explicit migrations for oauth2_provider seem to solve the problem. I appreciate you looking into this one.

And indeed, all seems to work fine with Django 1.7. I'm experiencing this behaviour only on 1.8.

@dustinfarris
Copy link
Contributor

Also see #224

SpaceFox added a commit to SpaceFox/zds-site that referenced this issue Apr 14, 2015
Impacts directs obligatoires :
- Une relation en base change de nom pour être python-compatible (et donc sa migration en base)
- On doit maintenant préciser le paramètre --fake-initial lors d'une migration de MAJ (cf https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake-initial)
- Debug Toolbar en v1.3
- Fix pour que oauth fonctionne, cf jazzband/django-oauth-toolkit#204
SpaceFox added a commit to SpaceFox/zds-site that referenced this issue May 14, 2015
Impacts directs obligatoires :
- Une relation en base change de nom pour être python-compatible (et donc sa migration en base)
- On doit maintenant préciser le paramètre --fake-initial lors d'une migration de MAJ (cf https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake-initial)
- Debug Toolbar en v1.3
- Fix pour que oauth fonctionne, cf jazzband/django-oauth-toolkit#204
@hicolour
Copy link

The best work around I found was, to run first of all migration for auth

migrate auth 
migrate

@arsenalstriker14
Copy link

hicolours solution was an easy fix for me as well on 1.8.2

artragis pushed a commit to artragis/zds-site that referenced this issue Nov 11, 2015
Impacts directs obligatoires :
- Une relation en base change de nom pour être python-compatible (et donc sa migration en base)
- On doit maintenant préciser le paramètre --fake-initial lors d'une migration de MAJ (cf https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake-initial)
- Debug Toolbar en v1.3
- Fix pour que oauth fonctionne, cf jazzband/django-oauth-toolkit#204
Emeric54 added a commit to Emeric54/zds-site that referenced this issue Feb 27, 2016
Freeze the version of `python-slugify` to 1.1.4 (fix zestedesavoir#3383)

(and provide a command to fix broken contents)

Also deal with contents that would have been created DURING v16.

Correct commit name

Ajout de notes pour éclaircir le but du fichier

Model._meta.module_name --> Model._meta.model_name

Cf https://docs.djangoproject.com/en/1.8/releases/1.8/#features-removed-in-1-8

Suppression du module inutilisé "django.contrib.sites"

S'il doit revenir, des modifications sont nécessaires.
Cf https://docs.djangoproject.com/en/1.8/releases/1.8/#django-contrib-sites

Django 1.8: Déclarer le dossier de fixtures par défaut lance une erreur

Donc on supprime cette déclaration qui était de toutes façons inutile même avec Django 1.7.
Cf https://docs.djangoproject.com/en/1.8/releases/1.8/#management-commands

Suppression d'une relation erronée

Django 1.8 vérifie ces relations et donc lancerait une erreur.
Cf https://docs.djangoproject.com/en/1.8/releases/1.8/#select-related-now-checks-given-fields

Utilisation d'une API privée qui a changée de package
Cf https://docs.djangoproject.com/en/1.8/releases/1.8/#cleanup-of-the-django-template-namespace

Passage à Django 1.8 minimal (il reste plein de warnings mais ça marche)

Impacts directs obligatoires :
- Une relation en base change de nom pour être python-compatible (et donc sa migration en base)
- On doit maintenant préciser le paramètre --fake-initial lors d'une migration de MAJ (cf https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake-initial)
- Debug Toolbar en v1.3
- Fix pour que oauth fonctionne, cf jazzband/django-oauth-toolkit#204

Une relation N..M nullable n'a pas de sens

Ce qui n'a pas de sens doit disparaître, d'autant plus que ça provoque des warnings.
Cf https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.ManyToManyField.allow_unsaved_instance_assignment

RedirectView.permanent va changer de valeur --> on la fixe

Cf https://docs.djangoproject.com/en/1.8/ref/class-based-views/base/#django.views.generic.base.RedirectView.permanent

django.utils.tzinfo est obsolète, remplacé par django.utils.timezone

Cf https://docs.djangoproject.com/fr/1.8/ref/utils/#django-utils-tzinfo

refactor(url): Utilisation nouvelle syntaxe dans les URLs.

- Change le format des urlpatterns.
- Utilise les vues dans la declaration des URLs.
- Correction de tous les reverse.
- Correction de toutes les balises url dans les templates.

refactor(1.8): Changement de l'import csrf.

https://docs.djangoproject.com/fr/1.8/ref/templates/api/#django.template.RequestContext

Correction d'un import

refactor(settings): Change la gestion des templates.

corrige les erreurs de tutorialv2 et munin

règle la migration et les avertissements de template du forum

refactor(form): Retire les warnings sur les forms.

refactor(migration): Supprime les migrations des vieux modules.

chore(dep): Mise a jour de django-debug-toolbar de 1.3.0 a 1.4.

chore(dep): Mise a jour de django-rest-swagger de 0.2.9 a 0.3..0.

chore(dep): Mise a jour de django_model_utils de 2.4 a 2.4.

chore(dep): Mise a jour de django-oauth-toolkit de 0.9.0 a 0.10.0.

chore(dep): Mise a jour de django-munin de 0.2.0 a 0.2.1.

chore(dep): Mise a jour de django-crispy-forms de 1.5.2 a 1.6.0.

chore(dep): Mise a jour de django-filter de 0.9.2 a 0.12.

chore(dep): Mise a jour de pillow de 2.9 a 3.1.1.

chore(dep): Mise a jour de DRF de 3.3.1 a 3.3.2.

Mise a jour de dependances connexes :
- drf-extensions de 0.2.7 a 0.2.8.
- django-cors-middleware de 1.0.0 a 1.2.0.
- Suppression de get_cache()
- Changement de noms de parametres de configuration pour REST_FRAMEWORK

Merci particulier a @DevHugo pour sa contribution.

Regle le soucis pour Travis et MySQL (merci @DevHugo)

Ajout des informations pour la mise en prod de la v17

chore(dep): Mise a jour de django de 1.7.10 a 1.8.9.

chore(dep): Mise a jour de coverage de 4.0.1 a 4.0.3.

chore(dep): Mise a jour de cairosvg de 1.0.13 a 1.0.19.

chore(dep): Mise a jour de beautifulsoup4 de 4.3.2 a 4.4.1.

chore(dep): Mise a jour de djangorestframework-xml de 1.0.1 a 1.3.0.

chore(dep): Mise a jour de factory-boy de 2.4.1 a 2.6.1.

Fix#3366: Ajout de l'extension de l'image

Fix#3234: Lien de retour à la liste des sujets

Affiche le karma en dessous des avatars (fix zestedesavoir#1444)

Corrige un petite erreur

Met à jour la documentation d'installation du front-end (fix zestedesavoir#3294)

Mail d'inscription

TU

Envoi par le validateur
@jleclanche
Copy link
Member

This is a non-issue now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants