2015-04-17 16 views
42

Durante l'aggiornamento a Django 1.8 (con zc.buildout) e in esecuzione syncdb o migrare, ottengo questo messaggio:errore auth_user con Django 1.8 e syncdb/migrare

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

Uno dei miei modelli contiene Django. contrib.auth.models.User:

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

Il downgrade a Django 1.7 elimina l'errore. Devo includere l'oggetto Utente in modo diverso in Django 1.8?

+1

Sul mio ambiente, questo solo accadere usando 'Postgre'. –

risposta

0

Prova riferendosi al Utente che utilizza questo

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) 
+0

Non funziona per me. Non ho migrazioni, sto solo cercando di eseguire ./manage.py test e l'errore subito quando viene eseguita la migrazione: django.db.utils.ProgrammingError: la relazione "auth_user" non esiste – radtek

+0

La correzione è di avere i tuoi modelli che contare su chiavi esterne per auth_model anche in fase di migrazione. Buone pratiche in generale dal momento che syncdb è andato in Django 1.9 – radtek

3

Per risolvere il problema qui è quello che ho fatto:

1) Trova tutti i campi di relazione di chiave esterna come OneToOneField, ForeignKey e ManyToManyFields nel progetto, incluse le app riutilizzabili che si riferiscono a auth.User o importate l'utente e impostarlo su settings.AUTH_USER_MODEL come sopra. Al minimo impiego:

'auth.User' 

2) Per tutti i modelli che hanno la precedenza, assicurarsi che i modelli hanno una migrazione Django valido (non a sud). Se hanno le migrazioni sud, rinominare la directory di migrations_south e quindi eseguire il comando makemigrations per questo app:

./manage.py makemigrations affected_app 

a volte c'è una cartella migrazioni Django con un nome diverso, non la directory di default migrations. In questi casi, fare riferimento a questo tramite MIGRATION_MODULES nel vostro settings.py:

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

Dal momento che il problema era difficile da trovare su grandi progetti, ho commentato tutte le applicazioni personalizzate in INSTALLED_APPS in settings.py e fatto funzionare l'ordine di prova, dal momento che verrà eseguito la migrazione e cercare di ricreare il database per voi:

./manage.py test 

Sembra quello fissato per me. Non sono sicuro che il passaggio 1 sia obbligatorio o solo la migliore pratica. Ma hai sicuramente bisogno di convertire le app in migrazioni.

Cheers!

PS. Preparati a ciò che sta arrivando in Django 1.9. Il comando syncdb verrà rimosso. Il metodo legacy di sincronizzazione delle app senza migrazioni viene rimosso e le migrazioni sono obbligatorie per tutte le app.

92

posso risolvere questo problema eseguendo auth per primo, poi il resto dei miei migrazioni:

python manage.py migrate auth 
python manage.py migrate 
+3

L'app di autenticazione dovrebbe già essere nella parte superiore di INSTALLED_APPS, ad esempio "django.contrib.admin", se nell'ordine corretto quanto sopra non dovrebbe fare la differenza. – radtek

+8

Ottengo 'relazione" django_site "non esiste'. Sono su django 1.8.2. Ho provato alcune app diverse nel mio progetto e ho sempre avuto lo stesso errore, poi ho eseguito di nuovo il comando 'python manage.py migrate', ed ecco che funzionava. – trpt4him

+1

Grazie, mi hai salvato –

17

Sul mio ambiente, posso risolvere questo correre makemigrations su tutte le applicazioni che hanno rapporto con django.contrib.auth.models:

 
manage.py makemigrations app_with_user_relation 
manage.py migrate 
+0

Ho avuto lo stesso problema e questa soluzione ha funzionato. Passando da Django 1.7.X a 1.8.1 – Daviddd

+0

Posso confermare che questo funziona ancora e da utilizzare con Heroku. – James

7

Se si utilizza Heroku come mi è stato eseguito

heroku run python manage.py makemigrations 

Questo probabilmente ti darà un messaggio che dice che ora ci sono cambiamenti.Ignora, quindi esegui

heroku run python manage.py migrate 

questo ti darà un risultato che suggerisce che qualcosa è stato fatto. Infine eseguire

heroku run python manage.py createsuperuser 
16

Ho anche avuto lo stesso problema ho risolto utilizzando questi:

python manage.py migrate auth 
python manage.py migrate 

quindi migrare fa il suo lavoro

+0

Ho appena provato e ha funzionato su un messaggio di errore simile – MaxouMask

+0

Ha funzionato benissimo, puoi fornire qualsiasi giustificazione a questa risposta o problema. –

6

Questo problema è contenuto eseguendo "makemigrations" per tutti app, che non sono ancora state migrate, ovvero app che non hanno ancora un file "initial_0001.py" nella loro directory di migrazione.

Questo viene fatto (nel nostro caso utilizziamo un makefile) eseguendo per ciascuna di queste applicazioni:

manage.py makemigrations app_name 

Una volta fatto ciò, è possibile eseguire:

manage.py migrate 

come al solito.

La causa di questo è che per qualche motivo

manage.py makemigrations 

fa non creare sempre queste migrazioni iniziali, se non sono già lì. E questo porta all'errore menzionato.

Al contrario,

manage.py makemigrations app_name 

fa creare sempre di loro (se non è già lì). Sfortunatamente non riesco a capire le ragioni di questa asimmetria.

+0

In quale directory si esegue il comando? Ottengo l'errore "Impossibile aprire il file manage.py". –

+1

È necessario eseguire tale comando all'interno della directory che contiene il file "manage.py". Puoi provare le seguenti 2 alternative: 1) anteponi il comando con dot-slash, in questo modo: "./manage.py makemigrations" o 2) antepone l'eseguibile python, in questo modo: "python manage.py makemigrations". In bocca al lupo. –

+0

Ma dove si trova questo? –

0

Ho migrato un vecchio progetto Django 1.6 in Django 1.8 e in precedenza abbiamo utilizzato syncdb per migrare il database e abbiamo fatto per non avere passaggi di migrazione iniziali per tutte le app del nostro progetto. Con Django 1.8, avrai bisogno di migrazioni di database funzionanti. In esecuzione

manage.py makemigrations <app_name> 

per tutte le app nel nostro progetto risolto i nostri problemi.

0

Forse hai trovato la risposta e risolto il problema, ma volevo sottolineare che, nel mio caso, il problema precedente è stato risolto rilasciando il database e ricrearlo di nuovo, con tutti i privilegi degli utenti . Sono stato in grado di farlo perché sto lavorando su un ambiente non di produzione, ma farlo su un ambiente di staging non è una buona idea, quindi fai attenzione.

Im usando python 2.7.12 e seguenti sono le specifiche della mia 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 
+0

Grazie mille "cavpollo" per la correzione. sembra decisamente meglio. –

+0

Eliminare e ricreare il database è stata l'unica cosa che ha funzionato per me. Dopo di ciò, ho eseguito python manage.py migrare, quindi il problema è stato risolto. Tutto quello che dovevo fare dopo era creare un altro superutente. – DevBot

Problemi correlati