Django 1.7 - makemigrations non rileva cambiamenti

Come dice il titolo, non riesco a far funzionare le migrazioni.

L'app era originariamente sotto 1.6, quindi capisco che le migrazioni inizialmente non ci saranno, e infatti se corro python manage.py migrateottengo:

Operations to perform:
  Synchronize unmigrated apps: myapp
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  No migrations to apply.

Se myappapporto una modifica a qualsiasi modello in , viene comunque indicato come non migrato, come previsto.

Ma se corro python manage.py makemigrations myappottengo:

No changes detected in app 'myapp'

Non sembra importare cosa o come eseguo il comando, non rileva mai l'app come se avesse delle modifiche, né aggiunge file di migrazione all'app.

Esiste un modo per forzare un'app sulle migrazioni e essenzialmente dire "Questa è la mia base su cui lavorare" o altro? Oppure mi sfugge qualcosa?

Il mio database è PostgreSQL se questo aiuta a tutti.

Se stai passando da un'app esistente creata in Django 1.6, devi fare un pre-passaggio (come ho scoperto) elencato nella documentazione:

python manage.py makemigrations your_app_label

La documentazione non rende ovvio che è necessario aggiungere l'etichetta dell'app al comando, poiché la prima cosa che ti dice di fare è python manage.py makemigrationsche fallirà. La migrazione iniziale viene eseguita quando crei l'app nella versione 1.7, ma se provenissi dalla 1.6 non sarebbe stata eseguita. Vedere "Aggiunta della migrazione alle app" nella documentazione per ulteriori dettagli.

Ciò può accadere per i seguenti motivi:

1. Non hai aggiunto l'app in INSTALLED_APPSelenco in settings.py (Devi aggiungere il nome dell'app o il percorso punteggiato alla sottoclasse di AppConfig in apps.py nella cartella dell'app, a seconda della versione di django che stai utilizzando). Consultare la documentazione: INSTALLED_APPS
2. Non hai migrations cartella dentro quelle app. (Soluzione: basta creare quella cartella).
3. Non hai __init__.pyfile nella migrationscartella di quelle app. (Soluzione: basta creare un file vuoto con nome __init__.py )
4. Non hai un __init__.pyfile nella cartella dell'app. (Soluzione: basta creare un file vuoto con nome __init__.py )
5. Non hai un models.py file nell'app
6. La tua classe Python (dovrebbe essere un modello) in models.py non ereditadjango.db.models.Model
7. Hai qualche errore semantico nella definizione di modelli in models.py

Nota: un errore comune è l'aggiunta di una migrationscartella nel .gitignorefile. Quando clonato da repository remoto,migrations cartelle e / oi __init__.pyfile mancheranno nel repository locale. Questo causa problemi.

Suggerisco di gitignore i file di migrazione aggiungendo le seguenti righe al .gitignorefile

*/migrations/*
!*/migrations/__init__.py

Ok, sembra che mi sia perso un passaggio ovvio, ma pubblicarlo nel caso in cui qualcun altro faccia lo stesso.

Durante l'aggiornamento a 1.7, i miei modelli sono diventati non gestiti ( managed = False) - li avevo comeTrue prima ma sembra che siano stati ripristinati.

La rimozione di quella riga (per impostazione predefinita su True) e l'esecuzione makemigrationsimmediata ha reso un modulo di migrazione e ora funziona. makemigrationsnon funzionerà su tabelle non gestite (il che è ovvio a posteriori)

La mia soluzione non è stata trattata qui, quindi la sto pubblicando. Stavo usandosyncdb per un progetto, solo per farlo funzionare. Poi, quando ho provato a iniziare a usare le migrazioni di Django, all'inizio le ho simulate, poi ho detto che era "OK" ma non stava accadendo nulla al database.

La mia soluzione era semplicemente eliminare tutti i file di migrazione per la mia app, nonché i record del database per le migrazioni dell'app nelladjango_migrations tabella.

Quindi ho appena effettuato una migrazione iniziale con:

./manage.py makemigrations my_app

seguito da:

./manage.py migrate my_app

Ora posso effettuare migrazioni senza problemi.

Concordo con @furins. Se tutto sembra essere in ordine e tuttavia si presenta questo problema, controlla se esiste un metodo di proprietà con lo stesso titolo dell'attributo che stai tentando di aggiungere nella classe Model.

1. Rimuovere il metodo con un nome simile come attributo che si sta aggiungendo.
2. manage.py makemigrations my_app
3. manage.py migrare my_app
4. Aggiungi i metodi indietro.

È una specie di stupido errore da fare, ma avere una virgola in più alla fine della riga di dichiarazione del campo nella classe del modello, rende la linea senza effetto.

Succede quando copi incolla il def. dalla migrazione, che a sua volta è definita come un array.

Anche se forse questo aiuterebbe qualcuno :-)

Forse sono troppo tardi, ma hai provato ad avere una migrationscartella nella tua app con un __init__.pyfile?

Forse questo aiuterà qualcuno. Stavo usando un'app nidificata. project.appname e in realtà avevo project e project.appname in INSTALLED_APPS. La rimozione del progetto da INSTALLED_APPS ha permesso di rilevare le modifiche.

La risposta è su questo post di StackOverflow, di cdvv7788 Migrations in Django 1.7

Se è la prima volta che esegui la migrazione di quell'app devi usare:

manage.py makemigrations myappname Una volta fatto ciò puoi fare:

manage.py migrate Se hai avuto la tua app nel database, modificato il suo modello e non aggiornando le modifiche sulle migrazioni probabilmente non hai ancora migrato. Riporta il tuo modello nella sua forma originale, esegui il primo comando (con il nome dell'app) ed esegui la migrazione ... lo falsificherà. Una volta fatto, rimetti le modifiche sul tuo modello, esegui makemigrations e migra di nuovo e dovrebbe funzionare.

Avevo lo stesso identico problema e fare quanto sopra ha funzionato perfettamente.

Avevo spostato la mia app django su cloud9 e per qualche motivo non ho mai rilevato la migrazione iniziale.

Di seguito ha funzionato per me:

1. Aggiungi il nome dell'app a settings.py
2. usa 'python manage.py makemigrations'
3. usa 'python manage.py migrate'

Ha funzionato per me: Python 3.4, Django 1.10

Le persone come me a cui non piacciono le migrazioni possono utilizzare i passaggi seguenti.

1. Rimuovi le modifiche da sincronizzare.
2. Correre python manage.py makemigrations app_label per la migrazione iniziale.
3. Correre python manage.py migrate per la creazione di tabelle prima di apportare modifiche.
4. Incolla le modifiche che rimuovi al primo passaggio.
5. Eseguire i passaggi 2. e 3..

Se hai confuso uno di questi passaggi, leggi i file di migrazione. Modificali per correggere il tuo schema o rimuovere i file indesiderati ma non dimenticare di cambiare la parte delle dipendenze del prossimo file di migrazione;)

Spero che questo possa aiutare qualcuno in futuro.

Vuoi controllare settings.pyinINSTALLED_APPS lista e assicurarsi che tutte le applicazioni con i modelli sono elencati in là.

L'esecuzione makemigrationsnella cartella del progetto significa che cercherà di aggiornare tutte le tabelle relative a tutte le app incluse nel settings.pyprogetto. Una volta inclusa, makemigrationsincluderà automaticamente l'app (ciò consente di risparmiare molto lavoro, quindi non è necessario eseguire makemigrations app_nameper ogni app nel progetto / sito).

Nel caso in cui tu abbia un campo specifico che non viene identificato dai makemigrations: controlla due volte se hai una proprietà con lo stesso nome.

esempio:

field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

la proprietà "sovrascriverà" la definizione del campo in modo che le modifiche non vengano identificate da makemigrations

Assicurati che il tuo modello non lo sia abstract. In realtà ho fatto quell'errore e ci è voluto un po ', quindi ho pensato di pubblicarlo.

Aggiungendo questa risposta perché solo questo metodo mi ha aiutato.

Ho eliminato la migrationscartella di esecuzione makemigrationse migrate.
Diceva ancora: nessuna migrazione da applicare.

Sono andato alla migratecartella e ho aperto l'ultimo file creato,
ho commentato la migrazione che volevo (è stata rilevata e inserita lì)
ed eseguito di migratenuovo.

Questo sostanzialmente modifica manualmente il file delle migrazioni.
Fallo solo se capisci il contenuto del file.

Hai usato schemamigration my_app --initialdopo aver rinominato la vecchia cartella di migrazione? Provalo. Potrebbe funzionare. In caso contrario, prova a ricreare il database e fai migrare syncdb +. Ha funzionato per me ...

Ho avuto lo stesso problema Assicurati che qualunque classe tu abbia definito in models.py, devi ereditare model.Model class.

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

Ho avuto lo stesso problema con la necessità di eseguire makemigrations due volte e ogni sorta di strano comportamento. Si è scoperto che la radice del problema era che stavo usando una funzione per impostare le date predefinite nei miei modelli in modo che le migrazioni rilevassero un cambiamento ogni volta che eseguivo makemigrations. La risposta a questa domanda mi ha messo sulla strada giusta: evitare le emigrazioni per ricreare il campo della data

Di recente ho aggiornato Django dalla 1.6 alla 1.8 e ho avuto poche app e migrazioni per loro. Ho usato il sud e schemamigrationsper creare migrazioni in Django 1.6, che è stato eliminato in Django 1.8.

Quando ho aggiunto nuovi modelli dopo l'aggiornamento, il makemigrationscomando non ha rilevato alcuna modifica. E poi ho provato la soluzione suggerita da @drojf (prima risposta), ha funzionato bene, ma non è stato possibile applicare la migrazione iniziale falsa ( python manage.py --fake-initial). Lo stavo facendo poiché i miei tavoli (vecchi tavoli) erano già stati creati.

Alla fine questo ha funzionato per me, ha rimosso nuovi modelli (o modifiche ai modelli) da models.py e quindi ha dovuto eliminare (o rinominare per il backup di sicurezza) la cartella delle migrazioni di tutte le app ed eseguire manage.pymakemigrations di Python per tutte le app, quindi ha fatto python manage.py migrate --fake-initial. Questo ha funzionato come un fascino. Una volta creata la migrazione iniziale per tutte le app e migrata la falsa iniziale, quindi aggiunti nuovi modelli e seguito il normale processo dimakemigrations migrazione di tale app. I cambiamenti sono stati rilevati ora e tutto è andato bene.

Ho solo pensato di condividerlo qui, se qualcuno dovesse affrontare lo stesso problema (avere schemamigrationsdel sud per le loro app), potrebbe aiutarli :)

Forse questo può aiutare qualcuno, ho avuto lo stesso problema.

Ho già creato due tabelle con la classe serializzatore e le viste. Quindi, quando volevo aggiornare, ho avuto questo errore.

Ho seguito questi passaggi:

1. ho fatto .\manage.py makemigrations app
2. L'ho giustiziato .\manage.py migrate
3. Ho cancellato entrambi i miei tavoli models.py
4. Ho cancellato tutti i riferimenti alle mie tabelle dal serializzatore e dalla classe di visualizzazione.
5. Ho eseguito il passaggio 1e 2.
6. Ho recuperato le mie modifiche solo in models.py
7. Ho eseguito di nuovo il passo 5.
8. Ho ripristinato tutte le mie modifiche.

Se lavori con Pycharm, la storia locale è molto utile.

Forse questo aiuterà qualcuno.

Ho cancellato il mio models.pye mi aspettavo makemigrationsdi creare DeleteModeldichiarazioni.

Ricorda di eliminare i *.pycfile!

./manage makemigrations
./manage migrate

Le migrazioni tengono traccia delle modifiche al DB, quindi se stai cambiando da non gestito a gestito, dovrai assicurarti che la tabella del database sia aggiornata in relazione al modello con cui hai a che fare.

Se si è ancora in modalità dev, ho deciso personalmente di eliminare i file di migrazione nel mio IDE, nonché nella tabella django_migrations relativa al mio modello ed eseguire nuovamente il comando sopra.

RICORDA: se hai una migrazione che termina con _001 nel tuo IDE e _003 nel tuo database. Django vedrà solo se hai una migrazione che termina con _004 per qualsiasi aggiornamento.

I 2 (migrazioni di codice e db) sono collegati e funzionano in tandem.

Buona codifica.

1. Rimuovi le modifiche da sincronizzare.
2. Esegui python manage.py makemigrations app_label per la migrazione iniziale.
3. Esegui python manage.py migrate per la creazione di tabelle prima di apportare modifiche.
4. Incolla le modifiche che rimuovi al primo passaggio.
5. Eseguire i passaggi 2. e 3.

Aggiunta questa risposta perché nessuna delle altre disponibili sopra ha funzionato per me.

Nel mio caso stava accadendo qualcosa di ancora più strano ( versione Django 1.7 ), In my models.py avevo una riga "extra" alla fine del mio file (era una riga vuota) e quando ho eseguito il python manage.py makemigrationscomando il risultato è stato: "nessuna modifica rilevata".

Per risolvere questo problema ho eliminato questa "riga vuota" che si trovava alla fine del mio file models.py e ho eseguito nuovamente il comando, tutto è stato corretto e sono state rilevate tutte le modifiche apportate a models.py !

Potrebbe essere necessario simulare le migrazioni iniziali utilizzando il comando seguente

python manage.py migrate --fake-initial

Innanzitutto questa soluzione è applicabile a coloro che si trovano ad affrontare lo stesso problema durante la distribuzione sul server Heroku, stavo affrontando lo stesso problema.

Per la distribuzione, è necessario un passaggio che consiste nell'aggiungere django_heroku.settings (locals ()) nel file settings.py.

Modifiche: quando ho cambiato la riga sopra in django_heroku.settings (locals (), databas = False), ha funzionato perfettamente.

Nel mio caso, dovevo aggiungere il mio modello al file _ init _.py della cartella dei modelli in cui era stato definito il mio modello:

from myapp.models.mymodel import MyModel

Aggiungendo il mio 2c, poiché nessuna di queste soluzioni ha funzionato per me, ma questo ha funzionato ...

Avevo appena eseguito manage.py squashmigrationse rimosso le vecchie migrazioni (sia i file che le righe nella tabella del database django.migrations).

Ciò ha lasciato una riga come questa nell'ultimo file di migrazione:

replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]

Questo apparentemente confuse Django e causò comportamenti strani: la corsa manage.py makemigrations my_appavrebbe ricreato la migrazione iniziale come se non esistesse. La rimozione della replaces...linea ha risolto il problema!

python manage.py makemigrations account Migrazioni per "account": account \ migrations \ 0001_initial.py - Crea modello Cliente - Crea modello Tag - Crea modello Prodotto - Crea modello Ordine

Nota: qui "account" è il nome della mia app