Django - makemigrations - Nessuna modifica rilevata


138

Stavo provando a creare migrazioni all'interno di un'app esistente usando il comando makemigrations ma produce "Nessuna modifica rilevata".

Di solito creo nuove app usando il startappcomando ma non l'ho usato per questa app quando l'ho creata.

Dopo il debug, ho scoperto che non sta creando la migrazione perché il migrationspacchetto / la cartella manca da un'app.

Sarebbe meglio se crea la cartella se non c'è o mi manca qualcosa?


13
L'app è stata aggiunta a INSTALLED_APPS?
Wolendranh,

6
Sì, è nell'app installata, per la prima volta, meglio usare makemigrations <myapp>come ha sottolineato anche Alasdair.
Dilraj,

1
Rimuovi 'abstract = True' :)
GrvTyagi

"makemigrations" non ha funzionato. 'makemigrations <myapp>' ha funzionato
Aseem il

Risposte:


267

Per creare migrazioni iniziali per un'app, esegui makemigrationse specifica il nome dell'app. Verrà creata la cartella delle migrazioni.

./manage.py makemigrations <myapp>

La tua app deve essere inclusa per INSTALLED_APPSprima (dentro settings.py).


15
Qualche idea sul perché ci <sometimes> ci costringono a specificare l'app?
Maazza,

40
@maazza è necessario specificare il nome dell'app se l'app non ha una migrationscartella. Ciò potrebbe accadere se hai creato l'app manualmente o se hai eseguito l'aggiornamento da una versione precedente di Django che non aveva migrazioni.
Alasdair,

13
@maazza In realtà hai bisogno di un pacchetto python (con __init__.py) chiamato 'migrations' nell'app.
Jibin,

3
Sembra qualcosa che Django dovrebbe gestire automaticamente.
dualità_4

1
@duality_ questo è di progettazione - Django non presume che tu voglia migrazioni per la tua app. Se ha creato migrazioni per tutte le app, potrebbe causare errori durante l'esecuzione migrate.
Alasdair,

49

Il mio problema (e quindi la soluzione) era ancora diverso da quelli sopra descritti.

Non stavo usando il models.pyfile, ma ho creato una modelsdirectory e creato il my_model.pyfile lì, dove ho messo il mio modello. Django non è riuscito a trovare il mio modello, quindi ha scritto che non ci sono migrazioni da applicare.

La mia soluzione era: nel my_app/models/__init__.pyfile ho aggiunto questa riga: from .my_model import MyModel


Questa è stata la soluzione anche per me, ma non capisco perché. Qualcuno ha qualche idea su cosa potrebbe causare questo?
Paul in 't Hout,

Django ha percorsi predefiniti su dove cercare i tuoi modelli. Se la struttura del progetto è diversa e i modelli non sono nella solita posizione, devono essere importati lì.
Karina Klinkevičiūtė,

@ KarinaKlinkevičiūtė cosa succede se devo rimuovere tali modelli?
Daniil Mashkin,

@DaniilMashkin Immagino che dovresti rimuovere anche le importazioni. Questo è uno dei modi per strutturare il tuo progetto (non l'unico) e devi occuparti delle attività aggiuntive che ne derivano se lo scegli :)
Karina Klinkevičiūtė

1
Ho usato l'architettura "classica" per i modelli, quindi sono passata all'architettura "cartella modelli" e qualsiasi migrazione viene ancora rilevata sui miei modelli esistenti. Tuttavia, ora, durante la creazione di un nuovo modello, ho questo problema. La tua soluzione funziona bene, ma rende il mio codebase incoerente perché a volte c'è un'importazione, a volte no. Forse c'è una soluzione migliore. Immagino che Django dovrebbe proporre un'impostazione con un elenco di cartelle da cercare quando si cerca di trovare nuovi modelli.
David D.

44

Ci sono molte possibili ragioni per cui django non rileva cosa migrare durante il makemigrationscomando.

  1. cartella di migrazione È necessario un pacchetto di migrazioni nella tua app.
  2. INSTALLED_APPS È necessario che l'app sia specificata nel INSTALLED_APPS.dict
  3. La verbosità inizia correndo makemigrations -v 3per la verbosità. Ciò potrebbe far luce sul problema.
  4. Percorso completo In INSTALLED_APPSsi consiglia di specificare il percorso di configurazione dell'app modulo completo 'apply.apps.MyAppConfig'
  5. --impostazioni che potresti voler accertare che sia impostato il file di impostazioni corretto:manage.py makemigrations --settings mysite.settings
  6. specifica il nome dell'app inserisci esplicitamente il nome dell'app manage.py makemigrations myapp, che restringe le migrazioni solo per l'app e ti aiuta a isolare il problema.
  7. verifica meta modello hai il diritto app_labelnella meta modello

  8. Debug django debug django core script. Il comando di makemigrations è piuttosto semplice. Ecco come farlo in Pycharm . modificare la definizione dello script di conseguenza (es: makemigrations --traceback myapp)

Database multipli:

  • Db Router quando si lavora con django db router, la classe router (la propria classe router personalizzata) deve implementare il allow_syncdbmetodo.

makemigrations crea sempre migrazioni per le modifiche del modello, ma se allow_migrate () restituisce False,


1
Coperti molti scenari riguardanti il ​​problema, dovrebbe essere la risposta accettata.
Krishh,

Un'altra possibilità: viene importato il nome sbagliato, ovvero l'importazione di un campo dai moduli anziché dai campi o l'importazione di un modello dai moduli anziché dai modelli. Un esempio: from recurrence.forms import RecurrenceFieldma avrebbe dovuto essere from recurrence.fields import RecurrenceField.
hlongmore,

Un motivo in più. Assicurarsi che il modello sia utilizzato all'interno di un percorso per il sito Web (tramite admin o in altro modo). "Lo makemigrationsscript cerca i modelli da cui sono collegati urls.py". Trovato qui stackoverflow.com/questions/43093651/…
Kyle il

Esempio cmd:python manage.py makemigrations -v 3 <app_name>
Charlie 木匠

Quando aggiungo una tabella e quindi aggiungo un riferimento di chiave esterna questa nuova tabella contemporaneamente. Deve essere diviso in 2 passaggi: pre passo: aggiungi INSTALLED_APPS alle impostazioni. 1) crea una nuova tabella: python manage.py makemigrations <app_name>; 2) aggiungi chiave esterna: python manage.py makemigrations
Charlie 木匠

26

Ho letto molte risposte a questa domanda affermando spesso di correre semplicemente makemigrationsin altri modi. Ma per me il problema era nella Metasottoclasse dei modelli.

Ho un'app di configurazione che dice label = <app name>(nel apps.pyfile, a fianco models.py, views.pyecc.). Se per caso la tua meta classe non ha la stessa etichetta dell'etichetta dell'app (ad esempio perché stai dividendo un'app troppo grande in più app), non vengono rilevate modifiche (e nessun messaggio di errore utile). Quindi nella mia classe di modello ho ora:

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

Eseguendo Django 1.10 qui.


13

È un commento ma probabilmente dovrebbe essere una risposta.

Assicurati che il nome della tua app sia in settings.py INSTALLED_APPSaltrimenti, qualunque cosa tu faccia, non eseguirà le migrazioni.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

Quindi eseguire:

./manage.py makemigrations blog

ma crea il nome della tabella come 'nome_model'app', quando eseguiamo il comando 'manage.py migrate'
Daniyal Javaid

Vedi le meta opzioni del modello per cambiare il nome della tabella
stephen

11

Ho avuto un altro problema non descritto qui, che mi ha fatto impazzire.

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

Ho avuto un "," finale in una riga forse da copia e incolla. La riga con is_dumb non ha creato una migrazione del modello con "./manage.py makemigrations" ma non ha generato alcun errore. Dopo aver rimosso "," ha funzionato come previsto.

Quindi fai attenzione quando copi e incolli :-)


La virgola finale può causare bug anche altrove; la virgola rende l'istruzione una tupla, quindi is_dumbè uguale alla (models.BooleanField(default=False), )quale makemigrationsnon sa come convertire in una colonna del database.
hlongmore,

8

A volte ci sono quando ./manage.py makemigrationsè superiore a ./manage.py makemigrations <myapp>perché può gestire alcuni conflitti tra app.

Quelle occasioni si verificano silenziosamente e ci vogliono diverse ore swearingper capire il vero significato del temuto No changes detectedmessaggio.

Pertanto, è una scelta molto migliore per utilizzare il seguente comando:

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>


7

Avevo copiato una tabella dall'esterno di django e la classe Meta era impostata su "managed = false". Per esempio:

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

Modificando Managed su True, i makemigrations hanno iniziato a raccogliere cambiamenti.


4
  1. Assicurati che la tua app sia menzionata ininstall_apps in settings.py
  2. Assicurati che la tua classe di modelli estenda modelli. Modello

2

Ho risolto il problema facendo questo:

  1. Cancella il file "db.sqlite3". Il problema qui è che la tua base di dati corrente verrà cancellata, quindi dovrai rifarla di nuovo.
  2. All'interno della cartella delle migrazioni dell'app modificata, cancella l'ultimo file aggiornato. Ricorda che il primo file creato è: "0001_initial.py". Ad esempio: ho creato una nuova classe e la ho registrata con la procedura "makemigrations" e "migrate", ora è stato creato un nuovo file chiamato "0002_auto_etc.py"; cancellalo.
  3. Vai alla cartella " pycache " (all'interno della cartella delle migrazioni) e cancella il file "0002_auto_etc.pyc".
  4. Infine, vai alla console e usa "python manage.py makemigrations" e "python manage.py migrate".

2

Ho dimenticato di mettere gli argomenti corretti:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

in models.py e poi ha iniziato a perdere quel fastidioso

Nessuna modifica rilevata nell'app 'myApp'


2

Un altro possibile motivo è se alcuni modelli sono stati definiti in un altro file (non in un pacchetto) e non sono stati citati altrove.

Per me, semplicemente aggiungendo from .graph_model import *a admin.py(dov'era graph_model.pyil nuovo file) risolto il problema.


2

Il mio problema era molto più semplice delle risposte di cui sopra e probabilmente un motivo molto più comune purché il progetto sia già impostato e funzionante. In una delle mie applicazioni che funzionava da molto tempo, le migrazioni sembravano instabili, quindi in fretta ho fatto quanto segue:

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

Whaat ??

Avevo erroneamente rimosso anche tutti i __init__.pyfile :( - Tutto funzionava di nuovo dopo essere entrato e:

touch ads1/migrations/__init__.py

Per ognuna delle mie applicazioni, poi ha makemigrationsfunzionato di nuovo.

Si è scoperto che avevo creato manualmente una nuova applicazione copiandone un'altra e ho dimenticato di metterlo __init__.pynella migrationscartella e questo mi ha confermato che tutto era traballante, portando il mio peggio con un rm -rcome descritto sopra.

Spero che questo aiuti qualcuno a giurare sull'errore "Nessuna modifica rilevata" per alcune ore.


1

La soluzione è che devi includere la tua app in INSTALLED_APPS.

L'ho perso e ho riscontrato lo stesso problema.

dopo aver specificato la migrazione del nome della mia app ha avuto esito positivo

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

si prega di notare che ho citato le schede in ultimo, che è il nome della mia app.


1

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

assicurati di "blog.apps.BlogConfig" (questo è incluso in settings.py per effettuare le migrazioni delle tue app)

quindi esegui il blog python3 manage.py makemigrations o il nome della tua app


1

Un problema molto stupido che puoi avere è quello di definirne due class Meta nel tuo modello. In tal caso, qualsiasi modifica alla prima non verrà applicata durante l'esecuzione makemigrations.

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]

1

So che questa è una vecchia domanda, ma ho combattuto con questo stesso problema tutto il giorno e la mia soluzione era semplice.

Ho avuto la mia struttura di directory qualcosa sulla falsariga di ...

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

E dal momento che tutti gli altri modelli fino a quello con cui ho avuto un problema venivano importati da qualche altra parte che finiva per importare da main_appcui era registrato nel INSTALLED_APPS, ho avuto la fortuna che funzionassero tutti.

Ma dal momento che ho aggiunto solo ogni appper INSTALLED_APPSe non il app_sub*quando finalmente aggiunto un nuovo file di modelli che non è stato importato qualsiasi altro luogo, Django totalmente ignorato.

La mia correzione era l'aggiunta di un models.pyfile alla directory di base di ciascuno appcome questo ...

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

e quindi aggiungere from apps.app.app_sub1 import *e così via a ciascuno dei file di applivello models.py.

Bleh ... mi ci è voluto tanto tempo per capire e non sono riuscito a trovare la soluzione da nessuna parte ... Sono anche andato alla pagina 2 dei risultati di Google.

Spero che questo aiuti qualcuno!


1

Ho avuto un problema simile con django 3.0, secondo la sezione sulle migrazioni nella documentazione ufficiale , eseguire questo è stato sufficiente per aggiornare la mia struttura della tabella:

python manage.py makemigrations
python manage.py migrate

Ma l'output è sempre stato lo stesso: "nessun cambiamento rilevato" sui miei modelli dopo aver eseguito lo script "makemigrations". Ho avuto un errore di sintassi su models.py sul modello che volevo aggiornare su db:

field_model : models.CharField(max_length=255, ...)

invece di:

field_model = models.CharField(max_length=255, ...)

Risolvendo questo stupido errore, con quei comandi la migrazione avveniva senza problemi. Forse questo aiuta qualcuno.


0

Dovresti aggiungere polls.apps.PollsConfiga INSTALLED_APPSinsetting.py


0

Nel mio caso ho dimenticato di inserire gli argomenti della classe

Sbagliato:

class AccountInformation():

Corretta

class AccountInformation(models.Model):

0

Nel mio caso, ho prima aggiunto un campo al modello e Django ha detto che non ci sono cambiamenti.

Di quanto ho deciso di cambiare il "nome della tabella" del modello, i makemigrations hanno funzionato. Quindi ho cambiato il nome della tabella di default e c'era anche il nuovo campo.

C'è un "bug" nel sistema di migrazione di django, a volte non vede il nuovo campo. Potrebbe essere correlato al campo della data.


0

Il possibile motivo potrebbe essere la cancellazione del file db esistente e della cartella delle migrazioni che è possibile utilizzare in Python manage.py makemigrations <app_name>. Una volta ho affrontato un problema simile.


0

Ancora una custodia e soluzione edge:

Ho aggiunto un campo booleano e allo stesso tempo ho aggiunto una proprietà @ facendo riferimento a esso, con lo stesso nome (doh). Ha commentato la proprietà e la migrazione vede e aggiunge il nuovo campo. Rinominato la proprietà e tutto va bene.


0

Se hai il managed = Truemodello in-yo Meta, devi rimuoverlo ed eseguire una migrazione. Quindi eseguire nuovamente le migrazioni, rileverà i nuovi aggiornamenti.


0

Quando si aggiungono nuovi modelli all'applicazione django api e si esegue python manage.py makemigrationslo strumento non viene rilevato alcun nuovo modello.

La cosa strana era che i vecchi modelli erano stati scelti da makemigrations, ma questo perché erano referenziati nella urlpatternscatena e lo strumento li rilevava in qualche modo. Quindi tieni d'occhio quel comportamento.

Il problema era dovuto al fatto che la struttura di directory corrispondente al pacchetto dei modelli aveva dei pacchetti secondari e tutti i __init__.pyfile erano vuoti. Devono importare esplicitamente tutte le classi richieste in ogni sottocartella e nei modelli __init__.py affinché Django le raccolga con lo makemigrationsstrumento.

models
  ├── __init__.py          <--- empty
  ├── patient
     ├── __init__.py      <--- empty
     ├── breed.py
     └── ...
  ├── timeline
     ├── __init__.py      <-- empty
     ├── event.py
     └── ...

0

Prova a registrare il tuo modello in admin.py, ecco un esempio: - admin.site.register (YourModelHere)

Puoi fare le seguenti cose: - 1. admin.site.register (YourModelHere) # In admin.py 2. Ricarica la pagina e riprova 3. Premi CTRL-S e salva 4. Potrebbe esserci un errore, controlla specialmente i modelli .py and admin.py 5. Oppure, alla fine, riavvia il server


0

Si spera che questo possa aiutare qualcun altro, dato che ho finito per passare ore a cercare di inseguirlo.

Se hai una funzione all'interno del tuo modello con lo stesso nome, questo rimuoverà il valore. Abbastanza ovvio col senno di poi, ma comunque.

Quindi, se hai qualcosa del genere:

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

In tal caso, la funzione sovrascriverà l'impostazione sopra, rendendola "invisibile" makemigrations.


0

La cosa migliore che puoi fare è, eliminare il database esistente. Nel mio caso, stavo usando il database SQL phpMyAdmin, quindi ho eliminato manualmente il database creato lì.

Dopo l'eliminazione: creo il database in PhpMyAdmin e non aggiungo alcuna tabella.

Eseguire di nuovo i seguenti comandi:

python manage.py makemigrations

python manage.py migrate

Dopo questi comandi : È possibile vedere django che ha creato automaticamente altre tabelle necessarie nel database (circa ci sono 10 tabelle).

python manage.py makemigrations <app_name>

python manage.py migrate

E infine: dopo i comandi precedenti, tutti i modelli (tabelle) creati vengono importati direttamente nel database.

Spero che questo possa aiutare.


0

Il mio problema con questo errore era che avevo incluso:

class Meta:
   abstract = True

All'interno del modello per cui volevo creare la migrazione.


0

Ho avuto un problema diverso durante la creazione di una nuova app chiamata deals. Volevo separare i modelli all'interno di quell'app quindi avevo 2 file di modello denominati deals.pye dealers.py. Durante la corsa python manage.py makemigrationsho ottenuto:No changes detected .

Sono andato avanti e dentro quello __init__.pyche vive nella stessa directory in cui vivevano i miei file modello (offerte e rivenditore)

from .deals import *
from .dealers import *

E poi il makemigrationscomando ha funzionato.

Si scopre che se non si importano i modelli ovunque O il nome del file dei modelli non lo è, models.pyi modelli non verranno rilevati.

Un altro problema che mi è successo è il modo in cui ho scritto l'app in settings.py:

Avevo:

apps.deals

Avrebbe dovuto includere la cartella del progetto principale:

cars.apps.deals
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.