auth_user Fehler mit Django 1.8 und syncdb/migrieren

Question

Wenn Django 1.8 (mit zc.buildout) ein Upgrade und Lauf syncdb oder migrieren, erhalte ich diese Meldung:

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

Einer meiner Modelle enthält django. contrib.auth.models.User:

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

Downgrade auf Django 1.7 entfernt den Fehler. Muss ich das Benutzerobjekt in Django 1.8 anders aufnehmen?

Answer 1

Versuchen Sie, den Benutzer unter Bezugnahme mit diesem

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 2

dieses Problem hier zu beheben ist, was ich tat:

1) Suche alle Fremdschlüssel Beziehung Felder wie OneToOneField, ForeignKey und ManyToManyFields in Ihrem Projekt, einschließlich aller wiederverwendbaren Apps, die sich auf auth.User beziehen oder Benutzer importieren und wie oben beschrieben auf settings.AUTH_USER_MODEL setzen. Bei minimaler Verwendung:

'auth.User' 

2) Für alle Modelle, die die oben haben, stellen Sie sicher, dass die Modelle eine gültige django Migration (nicht nach Süden). Wenn sie nach Süden Migrationen haben, benennen Sie das Verzeichnis migrations_south und dann dem makemigrations Befehl für diese Anwendung ausführen:

./manage.py makemigrations affected_app 

Manchmal gibt einen django Migrationen Ordner unter einem anderen Namen, nicht das Standard-migrations Verzeichnis. In solchen Fällen verweisen dies über MIGRATION_MODULES in Ihrem settings.py:

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

Da die Frage war hart größere Projekte zu finden, ich bemerkte aus allen benutzerdefinierten Anwendungen in INSTALLED_APPS in settings.py und lief den Testbefehl, da wird es laufen wandern und versuchen, die Datenbank für Sie neu zu erstellen:

./manage.py test 

aussieht, dass es für mich fixiert. Ich bin mir nicht sicher, ob Schritt 1 obligatorisch ist oder nur Best Practice. Aber Sie müssen die Apps definitiv in Migrationen umwandeln.

Prost!

PS. Sei bereit für was kommt in Django 1.9. Der syncdb-Befehl wird entfernt. Die herkömmliche Methode zum Synchronisieren von Apps ohne Migrationen wurde entfernt und Migrationen sind für alle Apps obligatorisch.

Answer 3

ich dieses Problem beheben, indem Auth läuft der Rest meiner Migrationen zuerst, dann:

python manage.py migrate auth 
python manage.py migrate 

Answer 4

Auf meiner Umgebung, ich dieses Problem beheben laufen makemigrations auf alle Anwendungen, die Beziehung mit django.contrib.auth.models:

 
manage.py makemigrations app_with_user_relation 
manage.py migrate 

Answer 5

Wenn Sie Heroku verwenden, wie ich ausgeführt wurde

Dies wird Ihnen wahrscheinlich eine Nachricht geben, dass es jetzt Änderungen gibt.Ignoriere das dann

heroku run python manage.py migrate 

Dies wird Ihnen etwas Ausgang, was darauf hindeutet, dass etwas getan worden ist. Schließlich laufen

heroku run python manage.py createsuperuser 

Answer 6

Ich hatte auch das gleiche Problem, das ich es durch die Verwendung gelöst diese:

python manage.py migrate auth 
python manage.py migrate 

Dann wandern macht seinen Job

Answer 7

Dieses Problem, indem Sie „makemigrations“ für alle enthalten ist Apps, die noch nicht migriert wurden, dh Apps, die noch keine Datei "initial_0001.py" in ihrem Migrationsverzeichnis haben.

Dies geschieht (in unserem Fall verwenden wir eine Make-Datei), indem für jede dieser Anwendungen ausgeführt werden:

manage.py makemigrations app_name 

Sobald das erledigt ist, können Sie ausführen:

manage.py migrate 

wie üblich.

Die zugrunde liegende Ursache dafür ist, dass

aus irgendeinem Grund

manage.py makemigrations 

tut nicht immer diese ersten Migrationen schaffen, wenn sie nicht bereits vorhanden sind. Und das führt zu dem erwähnten Fehler.

Im Gegenteil,

manage.py makemigrations app_name 

hat sie immer schaffen (wenn nicht bereits vorhanden). Leider kann ich die Gründe für diese Asymmetrie nicht ergründen.

Answer 8

Ich habe ein altes Django 1.6-Projekt nach Django 1.8 migriert und zuvor haben wir syncdb verwendet, um die Datenbank zu migrieren, und wir haben für alle Apps in unserem Projekt keine ersten Migrationsschritte. Mit Django 1.8 benötigen Sie eine funktionierende Datenbankmigration. Running

manage.py makemigrations <app_name> 

für alle Apps in unserem Projekt behoben unsere Probleme.

Answer 9

Vielleicht haben Sie die Antwort gefunden und das Problem gelöst, aber ich wollte darauf hinweisen, dass in meinem Fall das obige Problem gelöst wurde, indem die Datenbank gelöscht und mit den vollen Rechten der Benutzer neu erstellt wurde . Ich konnte dies tun, weil ich an einer Nicht-Produktionsumgebung arbeite, aber dies in einer Staging-Umgebung zu tun, ist keine gute Idee, also sei vorsichtig.

Im python 2.7.12 und nach Verwendung sind die Spezifikationen meines 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