Django - makemigrations - Nie wykryto żadnych zmian

160

Próbowałem utworzyć migracje w istniejącej aplikacji za pomocą polecenia makemigrations, ale wyświetla komunikat „Nie wykryto żadnych zmian”.

Zwykle tworzę nowe aplikacje za pomocą startapppolecenia, ale nie używałem go do tej aplikacji, kiedy ją tworzyłem.

Po debugowaniu stwierdziłem, że nie tworzy migracji, ponieważ w migrationsaplikacji brakuje pakietu / folderu.

Czy byłoby lepiej, gdyby utworzył folder, jeśli go tam nie ma, czy czegoś mi brakuje?

Dilraj
źródło
16
Czy masz swoją aplikację dodaną do INSTALLED_APPS?
wolendranh
8
Tak, jest w zainstalowanej aplikacji, po raz pierwszy lepiej go używać, makemigrations <myapp>jak również wskazał Alasdair.
Dilraj
1
Usuń „abstract = True” :)
GrvTyagi
1
„makemigracje” nie zadziałały. „makemigrations <myapp>” zadziałało
Aseem
W moim przypadku zmiany nie zostały wykryte, ponieważ klasy wewnątrz models.py nie dziedziczyły po models.Model. Po tym, jak klasy wewnątrz models.py dziedziczą po modelach.Model, np. MyDataClass (modeles.Model), problem został rozwiązany. Banalne, ale mam nadzieję, że to może komuś pomóc.
LMB

Odpowiedzi:

297

Aby utworzyć początkowe migracje dla aplikacji, uruchom makemigrationsi określ nazwę aplikacji. Zostanie utworzony folder migracji.

./manage.py makemigrations <myapp>

Twoja aplikacja musi być uwzględniona jako INSTALLED_APPSpierwsza (wewnątrz settings.py).

Alasdair
źródło
18
Masz jakiś pomysł, dlaczego <czasami> zmuszają nas do określenia aplikacji?
maazza
45
@maazza musisz określić nazwę aplikacji, jeśli aplikacja nie ma migrationsfolderu. Może się tak zdarzyć, jeśli utworzyłeś aplikację ręcznie lub zaktualizowałeś starszą wersję Django, która nie miała migracji.
Alasdair
13
@maazza Właściwie potrzebujesz pakietu Pythona (z __init__.py) o nazwie „migrations” w aplikacji.
Jibin,
3
Brzmi jak coś, co Django powinno obsługiwać automatycznie.
duality_
1
@duality_ jest to zgodne z projektem - Django nie zakłada, że ​​chcesz migrować swoją aplikację. Jeśli utworzył migracje dla wszystkich aplikacji, może to prowadzić do błędów podczas uruchamiania migrate.
Alasdair
54

Mój problem (a więc rozwiązanie) różnił się od opisanych powyżej.

Nie korzystałem z models.pypliku, ale utworzyłem modelskatalog i utworzyłem my_model.pytam plik, w którym umieściłem mój model. Django nie mógł znaleźć mojego modelu, więc napisał, że nie ma migracji do zastosowania.

Moje rozwiązanie brzmiało: w my_app/models/__init__.pypliku dodałem tę linię: from .my_model import MyModel

Karina Klinkevičiūtė
źródło
I to też było rozwiązaniem dla mnie, ale nie rozumiem, dlaczego tak jest. Czy ktoś ma jakiś wgląd w to, co może to powodować?
Paul in 't Hout
Django ma domyślne ścieżki, gdzie szukać modeli. Jeśli struktura projektu jest inna, a modele nie znajdują się w zwykłym miejscu, należy je tam zaimportować.
Karina Klinkevičiūtė
@ KarinaKlinkevičiūtė co jeśli muszę usunąć takie modele?
Daniil Mashkin,
@DaniilMashkin Wyobrażam sobie, że musiałbyś również usunąć import. To jeden ze sposobów na uporządkowanie projektu (nie jedyny) i musisz sobie poradzić z dodatkowymi zadaniami, które się z nim
wiążą,
1
Użyłem architektury „klasycznej” dla modeli, a następnie przeprowadziłem migrację do architektury „folderu modeli” i każda migracja jest nadal wykrywana w moich istniejących modelach. Jednak teraz podczas tworzenia nowego modelu mam ten problem. Twoje rozwiązanie działa dobrze, ale moja baza kodu jest nieco niespójna, ponieważ czasami występuje import, a czasami nie. Może jest lepsze rozwiązanie. Wydaje mi się, że Django powinien zaproponować ustawienia z listą folderów, których należy szukać, próbując znaleźć nowe modele.
David D.
50

Istnieje wiele możliwych powodów, dla których django nie wykrywa elementów do migracji podczas wykonywania makemigrationspolecenia.

  1. folder migracji Potrzebujesz pakietu migracji w swojej aplikacji.
  2. INSTALLED_APPS Twoja aplikacja musi być określona w INSTALLED_APPS.dict
  3. Oznajmianie zacznij od makemigrations -v 3wyszukania szczegółowości. To może rzucić trochę światła na problem.
  4. Pełna ścieżka W INSTALLED_APPSzaleca się podać pełną ścieżkę modułu app config „apply.apps.MyAppConfig”
  5. --settings możesz chcieć upewnić się, że ustawiono prawidłowy plik ustawień:manage.py makemigrations --settings mysite.settings
  6. określ nazwę aplikacji jawnie umieść nazwę aplikacji manage.py makemigrations myapp- to zawęża migracje samej aplikacji i pomaga w wyodrębnieniu problemu.
  7. model meta sprawdź masz prawo app_labelw swoim meta modelu

  8. Debugowanie django debugowanie podstawowego skryptu django. polecenie makemigrations jest dość proste. Oto jak to zrobić w pycharm . zmienić definicję skryptu odpowiednio (np makemigrations --traceback myapp)

Wiele baz danych:

  • Router Db Podczas pracy z routerem django db klasa routera (niestandardowa klasa routera) musi zaimplementować tę allow_syncdbmetodę.

makemigrations zawsze tworzy migracje dla zmian modelu, ale jeśli allow_migrate () zwraca False,

user1134422
źródło
1
Omówiono wiele scenariuszy dotyczących problemu, należy zaakceptować odpowiedź.
Krishh
Inna możliwość: Importowana jest niewłaściwa nazwa, tj. Importowanie pola z formularzy zamiast pól lub importowanie modelu z formularzy zamiast modeli. Przykład: from recurrence.forms import RecurrenceFieldale tak powinno być from recurrence.fields import RecurrenceField.
hlongmore
Jeszcze jeden powód. Upewnij się, że model jest używany w trasie dla witryny internetowej (przez administratora lub w inny sposób). „ makemigrationsSkrypt wyszukuje modele, z których są połączone urls.py”. Znaleziono tutaj stackoverflow.com/questions/43093651/ ...
Kyle
cmd przykład:python manage.py makemigrations -v 3 <app_name>
Charlie 木匠
Kiedy dodam tabelę, a następnie dodam klucz obcy, odwołuje się do tej nowej tabeli w tym samym czasie. Należy go podzielić na 2 kroki: krok wstępny: dodaj INSTALLED_APPS do ustawień. 1) utwórz nową tabelę: python manage.py makemigrations <app_name>; 2) dodaj klucz obcy: python manage.py makemigrations
Charlie 木匠
27

Przeczytałem wiele odpowiedzi na to pytanie, często stwierdzających, że po prostu biegnę makemigrationsw inny sposób. Ale dla mnie problem Metatkwił w podklasie modeli.

Mam app config, który mówi label = <app name>(w apps.pypliku, obok models.py, views.pyitp). Jeśli przypadkiem Twoja meta klasa nie ma tej samej etykiety, co etykieta aplikacji (na przykład, ponieważ dzielisz jedną zbyt dużą aplikację na wiele), nie wykryto żadnych zmian (ani żadnego pomocnego komunikatu o błędzie). Więc w mojej klasie modeli mam teraz:

class ModelClassName(models.Model):

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

    field_name = models.FloatField()
    ...

Uruchamiam Django 1.10 tutaj.

onekiloparsec
źródło
Co się stanie, jeśli w ogóle nie masz Meta? Jaką wartość przyjmuje app_labelwtedy jako domyślną?
ArtOfWarfare
14

To jest komentarz, ale prawdopodobnie powinna być odpowiedzią.

Upewnij się, że nazwa Twojej aplikacji znajduje się w settings.py, w INSTALLED_APPSprzeciwnym razie bez względu na to, co zrobisz, nie uruchomi migracji.

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

    'blog',
]

Następnie uruchomić:

./manage.py makemigrations blog
Stephen
źródło
ale tworzy nazwę tabeli jako „nazwa_aplikacji_nazwa_modelu”, gdy uruchamiamy polecenie „manage.py migrate”
Daniyal Javaid
Zobacz opcje meta modelu, aby zmienić nazwę tabeli
stephen
13

Miałem inny problem nie opisany tutaj, który doprowadził mnie do szału.

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

Na końcu miałem znak „,” być może w jednym wierszu z kopiowania i wklejania. Linia z is_dumb nie utworzyła migracji modelu z './manage.py makemigrations', ale również nie zgłosiła błędu. Po usunięciu znaku „” działało zgodnie z oczekiwaniami.

Uważaj więc podczas kopiowania i wklejania :-)

tak
źródło
1
Końcowy przecinek może również powodować błędy w innych miejscach; przecinek sprawia, że ​​instrukcja jest krotką, więc is_dumbjest równa liczbie, (models.BooleanField(default=False), )która makemigrationsnie wie, jak przekonwertować ją na kolumnę bazy danych.
hlongmore
wielkie dzięki, na pewno nie mogłem tego
rozgryźć
8

Czasami ./manage.py makemigrationsjest lepszy od, ./manage.py makemigrations <myapp>ponieważ może obsługiwać pewne konflikty między aplikacjami.

Okazje te odbywają się po cichu i swearingzrozumienie prawdziwego znaczenia przerażającej No changes detectedwiadomości zajmuje kilka godzin .

Dlatego znacznie lepszym wyborem jest użycie następującego polecenia:

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

raratiru
źródło
8

Skopiowałem tabelę spoza django, a klasa Meta ma domyślnie ustawioną wartość „managed = false”. Na przykład:

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'

Zmieniając zmieniony na True, makemigracje zaczęły przynosić zmiany.

Dan Cogswell
źródło
5
  1. Upewnij się, że Twoja aplikacja jest wymieniona w installed_apps w settings.py
  2. Upewnij się, że klasa modelu rozszerza modele
Amandeep Singh
źródło
5

Mój problem był znacznie prostszy niż powyższe odpowiedzi i prawdopodobnie znacznie częstszy powód, o ile Twój projekt jest już skonfigurowany i działa. W jednej z moich aplikacji, która działała przez długi czas, migracje wydawały się niepewne, więc w pośpiechu wykonałem następujące czynności:

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

Co ??

Pomyłkowo usunąłem też wszystkie __init__.pypliki :( - Po wejściu wszystko znowu działało i:

touch ads1/migrations/__init__.py

Dla każdej z moich aplikacji makemigrationsdziałało ponownie.

Okazuje się, że ręcznie utworzyłem nową aplikację, kopiując inną i zapomniałem umieścić __init__.pyw migrationsfolderze, a to ograniczyło mnie, że wszystko jest nieporęczne - co spowodowało, że pogorszyłem to, rm -rjak opisano powyżej.

Mam nadzieję, że pomoże to komuś przeklinać przez kilka godzin na błąd „Nie wykryto żadnych zmian”.

drchuck
źródło
3

Innym możliwym powodem jest to, że masz zdefiniowane modele w innym pliku (nie w pakiecie) i nigdzie indziej nie odwołujesz się do nich.

Dla mnie po prostu dodanie from .graph_model import *do admin.py(gdzie graph_model.pybył nowy plik) rozwiązało problem.

Nick Lothian
źródło
2

Rozwiązałem ten problem, wykonując następujące czynności:

  1. Usuń plik „db.sqlite3”. Problem polega na tym, że Twoja aktualna baza danych zostanie usunięta, więc będziesz musiał ją ponownie utworzyć.
  2. W folderze migracji edytowanej aplikacji usuń ostatni zaktualizowany plik. Pamiętaj, że pierwszy utworzony plik to: „0001_initial.py”. Na przykład: stworzyłem nową klasę i zarejestrowałem ją za pomocą procedury „makemigrations” i „migrate”, teraz został utworzony nowy plik o nazwie „0002_auto_etc.py”; wymazać to.
  3. Przejdź do folderu „ pycache ” (wewnątrz folderu migracji) i usuń plik „0002_auto_etc.pyc”.
  4. Na koniec przejdź do konsoli i użyj opcji „python manage.py makemigrations” i „python manage.py migrate”.
Juan David Argüello Plata
źródło
2

Zapomniałem podać poprawne argumenty:

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

w models.py, a potem zaczęło upuszczać to irytujące

Nie wykryto żadnych zmian w aplikacji „myApp”

CodeToLife
źródło
1

Rozwiązanie polega na tym, że musisz uwzględnić swoją aplikację w INSTALLED_APPS.

Brakowało mi tego i znalazłem ten sam problem.

po określeniu nazwy mojej aplikacji migracja zakończyła się pomyślnie

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

proszę zauważyć, że wspomniałem o tablicach na końcu, co jest nazwą mojej aplikacji.

śradha
źródło
1

INSTALLED_APPS = [

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

]

upewnij się, że „blog.apps.BlogConfig” (jest to zawarte w twoim settings.py, aby umożliwić migrację aplikacji)

następnie uruchom bloga python3 manage.py makemigrations lub nazwę swojej aplikacji

Piyush Chandra
źródło
1

Bardzo głupią kwestią, którą możesz mieć, jest zdefiniowanie dwóch class Metaw modelu. W takim przypadku żadna zmiana w stosunku do pierwszej nie zostanie zastosowana podczas uruchamiania 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")]
nbeuchat
źródło
1

Wiem, że to stare pytanie, ale cały dzień walczyłem z tym samym problemem i moje rozwiązanie było proste.

Miałem strukturę katalogów podobną do ...

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

A ponieważ wszystkie inne modele, aż do tego, z którym miałem problem, były importowane gdzie indziej, co skończyło się importem, z main_appktórego został zarejestrowany w INSTALLED_APPS, po prostu miałem szczęście, że wszystkie działały.

Ale ponieważ dodałem tylko każdy appz nich, INSTALLED_APPSa nie app_sub*wtedy, gdy w końcu dodałem nowy plik modeli, który nie był importowany GDZIEKOLWIEK więcej, Django całkowicie go zignorował.

Moja poprawka polegała na dodaniu models.pypliku do katalogu podstawowego każdego apptakiego ...

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

a następnie dodaj from apps.app.app_sub1 import *i tak dalej do każdego z plików apppoziomów models.py.

Bleh ... to zajęło mi TAK dużo czasu, aby się zorientować i nigdzie nie mogłem znaleźć rozwiązania ... nawet przeszedłem na drugą stronę wyników Google.

Mam nadzieję, że to komuś pomoże!

Tim
źródło
1

Jeszcze jedna skrajna sprawa i rozwiązanie:

Dodałem pole logiczne i jednocześnie dodałem odwołujące się do niego @property o tej samej nazwie (doh). Skomentowałem właściwość i migrację widzi i dodaje nowe pole. Zmieniono nazwę nieruchomości i wszystko jest w porządku.

kgeo
źródło
1

Podczas dodawania nowych modeli do aplikacji django api i uruchamiania python manage.py makemigrationsnarzędzie nie wykryło żadnych nowych modeli.

Dziwne było to, że stare modele zostały wybrane makemigrations, ale to dlatego, że były odniesienia w urlpatternsłańcuchu, a narzędzie w jakiś sposób je wykryło. Więc miej oko na to zachowanie.

Problem polegał na tym, że struktura katalogów odpowiadająca pakietowi modeli zawierała podpakiety, a wszystkie __init__.pypliki były puste. Muszą jawnie zaimportować wszystkie wymagane klasy z każdego podfolderu i modeli, __init__.py aby Django pobrał je za pomocą makemigrationsnarzędzia.

models
  ├── __init__.py          <--- empty
  ├── patient
  │   ├── __init__.py      <--- empty
  │   ├── breed.py
  │   └── ...
  ├── timeline
  │   ├── __init__.py      <-- empty
  │   ├── event.py
  │   └── ...
atoledo
źródło
1

Miałem podobny problem z django 3.0, zgodnie z sekcją migracji w oficjalnej dokumentacji , uruchomienie tego wystarczyło, aby zaktualizować strukturę mojej tabeli:

python manage.py makemigrations
python manage.py migrate

Ale wynik był zawsze taki sam: „nie wykryto żadnych zmian” w moich modelach po wykonaniu skryptu „makemigrations”. Wystąpił błąd składni w models.py w modelu, który chciałem zaktualizować w db:

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

zamiast:

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

Rozwiązując ten głupi błąd, z tymi komendami migracja odbyła się bez problemów. Może to komuś pomoże.

Yair Abad
źródło
1

Podczas tworzenia nowej aplikacji o nazwie deals. Chciałem oddzielić modele w tej aplikacji, więc miałem 2 pliki modeli o nazwach deals.pyi dealers.py. Podczas uruchamiania python manage.py makemigrationsmam: No changes detected.

Poszedłem do środka i __init__.pyznajdowałem się w tym samym katalogu, w którym znajdowały się moje pliki modeli (oferty i sprzedawca)

from .deals import *
from .dealers import *

I wtedy makemigrationspolecenie zadziałało.

Okazuje się, że jeśli nigdzie nie importujesz modeli LUB nazwa pliku modeli nie jest, models.pyto modele nie zostaną wykryte.

Kolejnym problemem, który mi się przydarzył, jest sposób, w jaki napisałem aplikację settings.py:

Miałem:

apps.deals

Powinien zawierać główny folder projektu:

cars.apps.deals
elad srebrny
źródło
0

Należy dodać polls.apps.PollsConfig, aby INSTALLED_APPSwsetting.py

Koteczek
źródło
0

W moim przypadku zapomniałem wstawić argumenty klasy

Źle:

class AccountInformation():

Poprawny

class AccountInformation(models.Model):
Jonas
źródło
0

W moim przypadku najpierw dodałem pole do modelu, a Django powiedział, że nie ma żadnych zmian.

Wtedy zdecydowałem się zmienić "nazwę tabeli" modelu, makemigracje zadziałały. Następnie zmieniłem nazwę tabeli z powrotem na domyślną, a nowe pole też tam było.

W systemie migracji django jest "błąd", czasami nie widzi on nowego pola. Może być związane z polem daty.

tolga
źródło
0

Możliwym powodem może być usunięcie istniejącego pliku db i folderu migracji. Możesz użyć Pythona, manage.py makemigrations <app_name>to powinno działać. Kiedyś miałem podobny problem.

Akash G Krishnan
źródło
0

Jeśli masz managed = Truemodel Meta in yout, musisz go usunąć i przeprowadzić migrację. Następnie ponownie uruchom migracje, wykryje nowe aktualizacje.

Irshu
źródło
0

Spróbuj zarejestrować swój model w admin.py, oto przykład: - admin.site.register (YourModelHere)

Możesz wykonać następujące czynności: - 1. admin.site.register (YourModelHere) # In admin.py 2. Ponownie załaduj stronę i spróbuj ponownie 3. Naciśnij CTRL-S i zapisz 4. Może wystąpić błąd, szczególnie sprawdź modele .py i admin.py 5. Lub na koniec po prostu zrestartuj serwer

GURU RAJ
źródło
0

Miejmy nadzieję, że to może pomóc komuś innemu, ponieważ spędziłem godziny na próbach ścigania tego.

Jeśli masz w modelu funkcję o tej samej nazwie, spowoduje to usunięcie wartości. Z perspektywy czasu dość oczywiste, niemniej jednak.

Więc jeśli masz coś takiego:

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

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

W takim przypadku funkcja zastąpi powyższe ustawienie, czyniąc ją „niewidoczną” dla makemigrations.

vpetersson
źródło
0

Najlepsze, co możesz zrobić, to usunąć istniejącą bazę danych. W moim przypadku korzystałem z bazy danych SQL phpMyAdmin, więc ręcznie usuwam utworzoną bazę danych.

Po usunięciu: tworzę bazę danych w PhpMyAdmin i nie dodaje żadnych tabel.

Ponownie uruchom następujące polecenia:

python manage.py makemigrations

python manage.py migrate

Po tych poleceniach : Możesz zobaczyć, że django automatycznie utworzył inne potrzebne tabele w bazie danych (w przybliżeniu jest 10 tabel).

python manage.py makemigrations <app_name>

python manage.py migrate

I wreszcie: po powyższych poleceniach cały utworzony model (tabela) jest bezpośrednio importowany do bazy danych.

Mam nadzieję, że to pomoże.

HITESH GUPTA
źródło
0

Mój problem z tym błędem polegał na tym, że dołączyłem:

class Meta:
   abstract = True

Model wewnętrzny, dla którego chciałem utworzyć migrację.

Dolidod Teethtard
źródło