erreur auth_user avec Django 1.8 et syncdb/migrate
Lors de la mise à niveau vers Django 1.8 (avec zc.buildout) et de l'exécution de syncdb ou de migrer, le message suivant s'affiche:
Django.db.utils.ProgrammingError: relation "auth_user" does not exist
Un de mes modèles contient Django.contrib.auth.models.User:
user = models.ForeignKey(
User, related_name='%(app_label)s_%(class)s_user',
blank=True, null=True, editable=False
)
La mise à niveau vers Django 1.7 supprime l'erreur. Dois-je inclure l'objet Utilisateur différemment dans Django 1.8?
Je résous ce problème en exécutant auth d'abord, puis le reste de mes migrations:
python manage.py migrate auth
python manage.py migrate
Sur mon environnement, je corrige cette makemigrations en cours d'exécution sur toutes les applications en relation avec Django.contrib.auth.models:
manage.py makemigrations app_with_user_relation manage.py migrate
J'ai également eu le même problème que j'ai résolu en utilisant ceux-ci:
python manage.py migrate auth
python manage.py migrate
Puis migrer fait son travail
Si vous utilisez heroku comme si j'étais couru
heroku run python manage.py makemigrations
Cela vous donnera probablement un message indiquant qu'il y a maintenant des changements. Ignorer ça puis courir
heroku run python manage.py migrate
cela vous donnera une sortie suggérant que quelque chose a été fait ..__ Enfin, lancez
heroku run python manage.py createsuperuser
Ce problème est contenu en exécutant "makemigrations" pour toutes les applications qui n’ont pas encore été migrées, c’est-à-dire les applications ne disposant pas encore de fichier "initial_0001.py" dans leur répertoire de migration.
Ceci est fait (dans notre cas, nous utilisons un makefile) en exécutant pour chacune de ces applications:
manage.py makemigrations app_name
Une fois que cela est fait, vous pouvez exécuter:
manage.py migrate
comme d'habitude.
La cause sous-jacente de ceci est que pour une raison quelconque
manage.py makemigrations
est-ce que pas crée toujours ces migrations initiales si elles ne sont pas déjà là? Et cela conduit à l'erreur mentionnée.
Au contraire,
manage.py makemigrations app_name
fait les crée toujours (si pas déjà là). Malheureusement, je ne peux pas comprendre les raisons de cette asymétrie.
Pour résoudre ce problème, voici ce que j'ai fait:
1) Recherchez tous les champs de relation de clé étrangère tels que OneToOneField, ForeignKey et ManyToManyFields dans votre projet, y compris les applications réutilisables faisant référence à auth.User ou importez l'utilisateur, puis définissez-le sur settings.AUTH_USER_MODEL comme indiqué ci-dessus. Au minimum utilisation:
'auth.User'
2) Pour tous les modèles ayant ce qui précède, assurez-vous qu’ils ont une migration Django valide (et non sud). S'ils effectuent des migrations vers le sud, renommez le répertoire en migrations_south, puis exécutez la commande makemigrations pour cette application:
./manage.py makemigrations affected_app
Parfois, il existe un dossier de migration Django sous un nom différent, pas le répertoire par défaut migrations. Dans de tels cas, faites référence à ceci via MIGRATION_MODULES dans votre fichier settings.py:
MIGRATION_MODULES = {'filer': 'filer.migrations_Django'}
Comme le problème était difficile à trouver sur des projets plus volumineux, j'ai commenté toutes les applications personnalisées dans INSTALLED_APPS dans settings.py et ai exécuté la commande test, puisqu’il exécutera migrate et tentera de recréer la base de données pour vous:
./manage.py test
On dirait que ça a réglé le problème pour moi. Je ne suis pas sûr si l'étape 1 est obligatoire ou simplement la meilleure pratique. Mais vous devez absolument convertir les applications en migrations.
À votre santé!
PS. Soyez prêt pour ce qui va arriver Django 1.9 . La commande syncdb sera supprimée. La méthode existante de synchronisation des applications sans migration est supprimée et les migrations sont obligatoires pour toutes les applications.
J'ai migré un ancien projet Django 1.6 vers Django 1.8 et nous avions précédemment utilisé syncdb pour migrer la base de données et nous n'avions nous n'avions pas les étapes de migration initiales pour toutes les applications de notre projet. Avec Django 1.8, vous aurez besoin d’une migration de base de données opérationnelle. Fonctionnement
manage.py makemigrations <app_name>
pour toutes les applications de notre projet résolu nos problèmes.
Essayez de faire référence à l'utilisateur utilisant cette
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)
Peut-être avez-vous trouvé la réponse et résolu le problème, mais je tiens à souligner que, dans mon cas, le problème ci-dessus a été résolu en supprimant la base de données et en la recréant à nouveau, avec tous les privilèges des utilisateurs. J'ai été capable de le faire car je travaille dans un environnement hors production, mais le faire dans un environnement de transfert n'est pas une bonne idée, alors soyez prudent.
J'utilise python 2.7.12 et voici les spécifications de mon 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