Django - makemigrations - Nie wykryto żadnych zmian

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?

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).

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

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,

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.

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

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 :-)

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>

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.

1. Upewnij się, że Twoja aplikacja jest wymieniona w installed_apps w settings.py
2. Upewnij się, że klasa modelu rozszerza modele

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”.

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.

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”.

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”

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.

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

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")]

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!

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.

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
  │   └── ...

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.

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

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

W moim przypadku zapomniałem wstawić argumenty klasy

Źle:

class AccountInformation():

Poprawny

class AccountInformation(models.Model):

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.

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.

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

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

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.

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.

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ę.