Django 1.7 - makemigracje nie wykrywają zmian

140

Jak mówi tytuł, wydaje mi się, że nie mogę uruchomić migracji.

Aplikacja była pierwotnie poniżej 1.6, więc rozumiem, że początkowo migracji tam nie będzie, a jeśli uruchomię python manage.py migrate, otrzymam:

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.

Jeśli wprowadzę zmiany w jakimkolwiek modelu w programie myapp, nadal będzie wyświetlany komunikat „nie migrowano”, zgodnie z oczekiwaniami.

Ale jeśli biegnę python manage.py makemigrations myapp, dostaję:

No changes detected in app 'myapp'

Wydaje się, że nie ma znaczenia, co ani jak uruchomię polecenie, nigdy nie wykrywa zmiany w aplikacji ani nie dodaje żadnych plików migracji do aplikacji.

Czy jest jakiś sposób, aby zmusić aplikację do migracji i powiedzieć „To jest moja baza do pracy” lub cokolwiek? A może coś mi brakuje?

Moja baza danych jest PostgreSQL, jeśli to w ogóle pomaga.

TyrantWave
źródło
Oferowane rozwiązania nie zadziałały dla mnie, więc oto moje rozwiązanie, jeśli ktoś napotka ten sam problem! 1. Usuń pliki migracji ze wszystkich aplikacji 2. Usuń bazę danych i utwórz ją ponownie 3. Uruchom polecenia makemigrations i migracji PS Spróbuj najpierw wykonać kroki 1 i 3. Jeśli nadal występuje błąd, wykonaj kroki 1-3.
Amoroso

Odpowiedzi:

187

Jeśli przechodzisz z istniejącej aplikacji, którą stworzyłeś w django 1.6, musisz wykonać jeden krok wstępny (jak się dowiedziałem) wymieniony w dokumentacji:

python manage.py makemigrations your_app_label

Dokumentacja nie wyjaśnia, że ​​musisz dodać etykietę aplikacji do polecenia, ponieważ pierwszą rzeczą, którą nakazuje, jest to, python manage.py makemigrationsco się nie powiedzie. Początkowa migracja jest wykonywana podczas tworzenia aplikacji w wersji 1.7, ale gdybyś pochodził z wersji 1.6, nie zostałaby przeprowadzona. Aby uzyskać więcej informacji, zobacz „Dodawanie migracji do aplikacji” w dokumentacji.

drojf
źródło
1
Dobra odpowiedź dla osób pochodzących z Django 1.6! Dzięki!
David D.
1
A jeśli mam więcej niż jedną aplikację? Czy powinienem mieć to python manage.py makemigrations APP_LABELdla każdego?
Alston,
1
Pod Django 1.9 tutaj i moja aplikacja została stworzona z ./manage.py startapp, ale nadal musiałem wyraźnie wspomnieć o etykiecie
maxbellec
50

Może się to zdarzyć z następujących powodów:

  1. Nie dodałeś aplikacji na INSTALLED_APPSliście w settings.py (musisz dodać nazwę aplikacji lub kropkowaną ścieżkę do podklasy AppConfig w apps.py w folderze aplikacji, w zależności od używanej wersji django). Zapoznaj się z dokumentacją: INSTALLED_APPS
  2. Nie masz migrationsfolderu w tych aplikacjach. (Rozwiązanie: po prostu utwórz ten folder).
  3. Nie masz __init__.pypliku w migrationsfolderze tych aplikacji. (Rozwiązanie: po prostu utwórz pusty plik o nazwie __init__.py )
  4. Nie masz __init__.pypliku w folderze aplikacji. (Rozwiązanie: po prostu utwórz pusty plik o nazwie __init__.py )
  5. Nie masz models.pypliku w aplikacji
  6. Twoja klasa Pythona (rzekomo model) w models.pynie dziedziczydjango.db.models.Model
  7. Masz błąd semantyczny w definicji modeli w programie models.py

Uwaga: częstym błędem jest dodawanie migrationsfolderu w .gitignorepliku. Po sklonowaniu ze zdalnego repozytorium w lokalnym repozytorium nie będzie brakować migrationsfolderu i / lub __init__.pyplików. To powoduje problem.

Proponuję pliki migracji gitignore, dodając następujące wiersze do .gitignorepliku

*/migrations/*
!*/migrations/__init__.py
Mohammed Shareef C.
źródło
1
Sklonowałem mój projekt, a folder migracji nie został wypchnięty do repozytorium, więc musiałem dodać dyrektora migracji, a następnie dodałem plik init .py i mogłem wykonywać migracje. Dziękuję
Junaid
Usunąłem zawartość mojego folderu / migrations, aby „zresetować” rzeczy w projekcie, którego jeszcze nie wdrożyłem. Nieumyślnie usunąłem __init__.pyfolder wraz z migracjami.
Seth
You don't have __init__.py file inside migrations folder of those apps. (Solution: Just create an empty file with name __init__.py).gitignore
Zrobiło
1
Dlaczego plik init .py jest tak ważny w folderze migracji? dokonać migracji? Gdzie mogę głębiej zagłębić się w tę logikę?
Nimish Bansal
1
Plik @NimishBansal do pythona 3.3 __init__.pyjest wymagany w katalogu, aby był traktowany jako pakiet Pythona. zobacz to
Mohammed Shareef C
29

Ok, wygląda na to, że przegapiłem oczywisty krok, ale publikowanie tego na wypadek, gdyby ktoś inny zrobił to samo.

Po aktualizacji do wersji 1.7 moje modele stały się niezarządzane ( managed = False) - miałem je jak Truepoprzednio, ale wygląda na to, że zostały przywrócone.

Usunięcie tego wiersza (To default na True) i makemigrationsnatychmiastowe uruchomienie spowodowało, że moduł migracji i teraz działa. makemigrationsnie będzie działać na niezarządzanych tabelach (co jest oczywiste z perspektywy czasu)

TyrantWave
źródło
4
Proszę wyjaśnić - gdzie zmieniłeś / dodałeś „managed = False”? Mam ten sam problem
Ycon
1
Nie mam już tego kodu, ale myślę, że jest to właściwość klasy, jeśli dobrze pamiętam.
TyrantWave
1
Słuszna uwaga. Zauważ, że manage.py inspectdbdodaje manage = False! jeśli importujesz starsze bazy danych, musisz je ostrożnie dostroić!
Alessandro Dentella
@TyrantWave, uratowałeś mi dzień. Wielkie dzięki.
Utkarsh Sharma
upewnij się, że jesteś app_labeltaki sam
Luv33preet
19

Moje rozwiązanie nie zostało tutaj uwzględnione, więc je publikuję. Używałem go syncdbdo projektu - tylko po to, aby go uruchomić. Potem, kiedy próbowałem zacząć używać migracji Django, najpierw je sfałszował, a potem powiedział, że jest OK, ale nic się nie dzieje z bazą danych.

Moim rozwiązaniem było po prostu usunięcie wszystkich plików migracji dla mojej aplikacji, a także rekordów bazy danych dotyczących migracji aplikacji w django_migrationstabeli.

Potem właśnie wykonałem wstępną migrację z:

./manage.py makemigrations my_app

śledzony przez:

./manage.py migrate my_app

Teraz mogę bez problemu dokonywać migracji.

Grant Eagon
źródło
Do Twojej wiadomości: ważne jest, aby powiedział tutaj: „pliki, a także rekordy bazy danych”. Jeśli usuniesz rekordy bazy danych, ale nie również pliki (z wyjątkiem __init.py__, to nie zadziała.
Mike Robinson
15

Zgadzam się z @furins. Jeśli wydaje się, że wszystko jest w porządku, a mimo to pojawia się ten problem, sprawdź, czy istnieje metoda właściwości o tym samym tytule, co atrybut, który próbujesz dodać w klasie Model.

  1. Usuń metodę o podobnej nazwie jak dodawany atrybut.
  2. manage.py makemigrations my_app
  3. manage.py migrate my_app
  4. Dodaj metody z powrotem.
Prashant Nair
źródło
11

Jest to trochę głupi błąd do popełnienia, ale dodatkowy przecinek na końcu wiersza deklaracji pola w klasie modelu sprawia, że ​​wiersz nie ma żadnego efektu.

Dzieje się tak, gdy kopiujesz, wklejasz plik def. z migracji, która sama jest zdefiniowana jako tablica.

Choć może to komuś pomogło :-)

Iman Akbari
źródło
1
Twój komentarz pomógł mi znaleźć mój problem! Nie miałem przecinka na końcu ostatniego wyboru na liście wyborów… najwyraźniej Django jest bardzo drażliwy.
Maxim
1
@Maxim: to była mało prawdopodobna przyczyna twojego problemu: lista bez przecinka na końcu nadal jest listą. Inną sprawą są krotki: jeśli masz tylko 1 element w krotce, potrzebujesz po nim przecinka.
blueFast
koleś, który zaoszczędził mi dużo czasu! @dangonfast: w definicji modelu jest to rzeczywiście problem.
Pan E,
11

Może spóźniłem się, ale czy próbowałeś mieć migrationsfolder w swojej aplikacji z __init__.pyplikiem?

rrrub
źródło
1
Jeśli masz to „makemigrations”, utworzysz migracje dla aplikacji. W przeciwnym razie będzie wymagać uruchomienia makemigrations nazwa_aplikacji (która tworzy ten plik)
Scott Warren,
7

Może to komuś pomoże. Używałem aplikacji zagnieżdżonej. project.appname i faktycznie miałem projekt i project.appname w INSTALLED_APPS. Usunięcie projektu z INSTALLED_APPS umożliwiło wykrycie zmian.

jaywhy13
źródło
7

Odpowiedź znajduje się w tym poście o przepełnieniu stosu, opublikowanym przez cdvv7788 Migrations in Django 1.7

Jeśli migrujesz tę aplikację po raz pierwszy, musisz użyć:

manage.py makemigrations myappname Gdy to zrobisz, możesz zrobić:

manage.py migrate Jeśli masz aplikację w bazie danych, zmodyfikowałeś jej model i nie aktualizowałeś zmian podczas makemigracji, prawdopodobnie jeszcze jej nie migrowałeś. Zmień model z powrotem do jego pierwotnej postaci, uruchom pierwsze polecenie (z nazwą aplikacji) i przeprowadź migrację ... to sfałszuje. Gdy to zrobisz, przywróć zmiany w modelu, uruchom makemigrations i ponownie przeprowadź migrację i powinno działać.

Miałem dokładnie ten sam problem i wykonanie powyższego zadziałało idealnie.

Przeniosłem moją aplikację django do cloud9 iz jakiegoś powodu nigdy nie złapałem początkowej migracji.

MicahT
źródło
7

Pracowały dla mnie następujące:

  1. Dodaj nazwę aplikacji do settings.py
  2. użyj „python manage.py makemigrations”
  3. użyj „python manage.py migrate”

Pracowało dla mnie: Python 3.4, Django 1.10

Pranshu Gupta
źródło
6

Osoby takie jak ja, które nie lubią migracji, mogą skorzystać z poniższych kroków.

  1. Usuń zmiany, które chcesz zsynchronizować.
  2. Uruchom python manage.py makemigrations app_labeldo początkowej migracji.
  3. Uruchom python manage.py migratedo tworzenia tabel przed wprowadzeniem zmian.
  4. Wklej zmiany, które usuniesz w pierwszym kroku.
  5. Uruchom kroki 2. i 3..

Jeśli pomylisz którykolwiek z tych kroków, przeczytaj pliki migracji. Zmień je, aby poprawić swój schemat lub usunąć niechciane pliki, ale nie zapomnij zmienić części zależności następnego pliku migracji;)

Mam nadzieję, że to pomoże komuś w przyszłości.

Deniz Kaplan
źródło
5

Chcesz sprawdzić settings.pywINSTALLED_APPS wykazie i sprawdzić, czy wszystkie aplikacje z modeli są wymienione tam.

Uruchomienie makemigrationsw folderze projektu oznacza, że ​​będzie szukał aktualizacji wszystkich tabel związanych ze wszystkimi aplikacjami zawartymi w settings.pyprojekcie. Po dołączeniu makemigrationsautomatycznie dołączy aplikację (oszczędza to dużo pracy, więc nie musisz uruchamiać makemigrations app_namedla każdej aplikacji w projekcie / witrynie).

Lepki
źródło
5

Na wszelki wypadek, gdybyś miał określone pole, które nie jest identyfikowane przez makemigracje: sprawdź dwukrotnie, czy masz właściwość o tej samej nazwie.

przykład:

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

# ... later

@property
def field(self):
    pass

właściwość „nadpisze” definicję pola, więc zmiany nie zostaną zidentyfikowane przez makemigrations

furiny
źródło
Powiązanym błędem jest posiadanie zniekształconego pola, które nadal nie może zostać poddane walidacji / sprawdzeniu. Zdefiniowałem hourly_rate = models.DecimalField(pomijając końcowy znak „()”) i po prostu cicho się nie udało.
mędrzec
5

Upewnij się, że Twój model nie jest abstract. Właściwie popełniłem ten błąd i zajęło to trochę czasu, więc pomyślałem, że opublikuję go.

znak
źródło
4

Dodanie tej odpowiedzi bo pomogła mi tylko ta metoda.

Usunąłem migrationsfolder run makemigrationsi migrate.
Nadal brzmiał: Brak migracji do zastosowania.

Poszedłem do migratefolderu i otworzyłem ostatnio utworzony plik,
skomentowałem migrację, którą chciałem (została tam wykryta i wprowadzona)
i uruchomiłemmigrate ponownie.

To po prostu ręczna edycja pliku migracji.
Zrób to tylko wtedy, gdy rozumiesz zawartość pliku.

Jithin Pavithran
źródło
1
Dziękuję bardzo! To pomogło
Sharpless512
3

Czy używałeś schemamigration my_app --initialpo zmianie nazwy starego folderu migracji? Spróbuj. Może działać. Jeśli nie - spróbuj odtworzyć bazę danych i wykonaj synchronizację + migrację. U mnie zadziałało ...

Alex Vidis
źródło
10
Nie schemamigrationistnieje żadne polecenie - myślę, że to część południa? Obecnie w ogóle nie mam folderu migracji. Usunięcie models.pyi ponowne uruchomienie inspectdbnie wydawało się nic zrobić.
TyrantWave
2
schemamigrationbył z południa. makemigrationsjest jego zamiennikiem.
Craig Labenz
2
To jest nadal aktualne. Ale zmieniło się namakemigrations --empty
Iulius Curt
2

Miałem ten sam problem. Upewnij się, że niezależnie od klas, które zdefiniowałeś w models.py, musisz dziedziczyć modeles.Model class.

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()
Sonu Kumar
źródło
1

Miałem ten sam problem z koniecznością dwukrotnego przeprowadzania makemigracji i wszelkiego rodzaju dziwnych zachowań. Okazało się, że przyczyną problemu było to, że korzystałem z funkcji ustawiania domyślnych dat w moich modelach, więc migracje wykrywały zmianę za każdym razem, gdy wykonywałem makemigracje. Odpowiedź na to pytanie postawiła mnie na właściwej drodze: unikaj makemigracji, aby ponownie utworzyć pole daty

PhoebeB
źródło
1

Niedawno zaktualizowałem Django z wersji 1.6 do 1.8 i miałem dla nich kilka aplikacji i migracji. Użyłem południe i schemamigrationsdo tworzenia migracji w Django 1.6, które zostało usunięte w Django 1.8.

Kiedy dodałem nowe modele po aktualizacji, makemigrationspolecenie nie wykryło żadnych zmian. A potem wypróbowałem rozwiązanie sugerowane przez @drojf (pierwsza odpowiedź), działało dobrze, ale nie udało mi się zastosować fałszywej migracji początkowej (python manage.py --fake-initial ). Robiłem to, ponieważ moje tabele (stare tabele) były już utworzone.

W końcu zadziałało to dla mnie, usunęło nowe modele (lub zmiany modelu) z models.py, a następnie musiałem usunąć (lub zmienić nazwę dla bezpiecznej kopii zapasowej) folder migracji wszystkich aplikacji i uruchomić manage.pymakemigracje Pythona dla wszystkich aplikacji, a następnie tak się stało python manage.py migrate --fake-initial. To zadziałało jak urok. Po utworzeniu początkowej migracji dla wszystkich aplikacji i fałszywej wstępnej migracji, następnie dodano nowe modele i postępowano zgodnie z regularnym procesem makemigrationsi migracją do tej aplikacji. Zmiany zostały wykryte teraz i wszystko poszło dobrze.

Pomyślałem o udostępnieniu go tutaj, jeśli ktoś napotka ten sam problem (posiadanie schemamigrationspołudnia dla swoich aplikacji), może mu to pomóc :)

RaghavHarpale
źródło
1

Może to komuś pomoże, miałem ten sam problem.

Utworzyłem już dwie tabele z klasą serializatora i widokami. Więc kiedy chciałem zaktualizować, miałem ten błąd.

Wykonałem następujące kroki:

  1. zrobiłem .\manage.py makemigrations app
  2. Wykonałem .\manage.py migrate
  3. Wymazałem obie tabele models.py
  4. Usunąłem wszystkie odwołania do moich tabel z serializatora i klasy widoku.
  5. Wykonałem krok 1i 2.
  6. Pobrałem swoje zmiany tylko w models.py
  7. Wykonałem ponownie krok 5.
  8. Przywróciłem wszystkie swoje zmiany.

Jeśli pracujesz z Pycharm, lokalna historia jest bardzo pomocna.

odciski palców
źródło
1

Może to komuś pomoże.

Usunąłem moje models.pyi spodziewałem makemigrationssię stworzyć DeleteModelzestawienia.

Pamiętaj, aby usunąć *.pycpliki!

Sebastian Wagner
źródło
1
./manage makemigrations
./manage migrate

Migracje śledzą zmiany w DB, więc jeśli zmieniasz się z niezarządzanego na zarządzany, musisz upewnić się, że twoja tabela bazy danych jest aktualna w odniesieniu do modelu, z którym masz do czynienia.

Jeśli nadal jesteś w trybie deweloperskim, osobiście zdecydowałem się usunąć pliki migracji w moim IDE, a także w tabeli django_migrations związanej z moim modelem i ponownie uruchomić powyższe polecenie.

PAMIĘTAJ: jeśli masz migrację, która kończy się na _001 w twoim IDE i _003 w twojej bazie danych. Django zobaczy tylko, czy masz migrację kończącą się na _004, aby cokolwiek zaktualizować.

Te 2 (migracje kodu i bazy danych) są połączone i działają w tandemie.

Miłego kodowania.

AH Bensiali
źródło
1
  1. Usuń zmiany, które chcesz zsynchronizować.
  2. Uruchom python manage.py makemigrations app_label dla początkowej migracji.
  3. Uruchom python manage.py migrate, aby utworzyć tabele przed wprowadzeniem zmian.
  4. Wklej zmiany, które usuniesz w pierwszym kroku.
  5. Uruchom kroki 2. i 3.
Vijay Choudhary
źródło
0

Dodałem tę odpowiedź, ponieważ żadna z innych dostępnych powyżej nie działała dla mnie.

W moim przypadku działo się coś jeszcze bardziej dziwnego ( wersja Django 1.7 ), w moim models.py miałem „dodatkową” linię na końcu mojego pliku (była to pusta linia) i kiedy wykonałem python manage.py makemigrationspolecenie, wynik był taki: „nie wykryto żadnych zmian”.

Aby to naprawić, usunąłem„pustą linię”, która znajdowała się na końcu mojego pliku models.py i ponownie uruchomiłem polecenie, wszystko zostało naprawione i wykryto wszystkie zmiany wprowadzone w models.py !

Huskie
źródło
Cóż, w django 2.0 + ta pusta linia jest wymagana, wierzę, że musiałem zrobić coś odwrotnego niż to, co zrobiłeś kolego
Sumit Kumar Saha
@SumitKumarSaha haha ​​Używam obecnie wersji Django 1.7 i ta pusta linia była powodem 2 godzin próbowania wszystkiego, aby rozwiązać błąd migracji. Dzięki za udostępnienie Sumit. Miłego dnia
Huskie
0

Może być konieczne sfałszowanie początkowych migracji za pomocą poniższego polecenia

python manage.py migrate --fake-initial
dtar
źródło
0

Po pierwsze to rozwiązanie ma zastosowanie do tych, którzy mają ten sam problem podczas wdrażania na serwerze heroku, ja miałem ten sam problem.

Aby wdrożyć, jest obowiązkowy krok, który polega na dodaniu django_heroku.settings (locals ()) w pliku settings.py.

Zmiany: Kiedy zmieniłem powyższą linię na django_heroku.settings (locals (), databases = False), działało bezbłędnie.

Rishabh Aher
źródło
0

W moim przypadku musiałem dodać mój model do pliku _ init _.py w folderze models, w którym został zdefiniowany mój model:

from myapp.models.mymodel import MyModel
Robert Wallace
źródło
-1

Dodanie mojego 2c, ponieważ żadne z tych rozwiązań nie zadziałało, ale to ...

Właśnie uruchomiłem manage.py squashmigrationsi usunąłem stare migracje (zarówno pliki, jak i wiersze w tabeli bazy danych django.migrations).

To pozostawiło taką linię w ostatnim pliku migracji:

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

To najwyraźniej zdezorientowało Django i spowodowało dziwne zachowanie: uruchomienie manage.py makemigrations my_appodtworzyłoby początkową migrację, tak jakby żadna nie istniała. Usunięcie replaces...linki rozwiązało problem!

webtweakers
źródło
-1

python manage.py makemigrations accounts Migracje dla 'accounts': accounts \ migrations \ 0001_initial.py - Utwórz model Klient - Utwórz model Tag - Utwórz model Produkt - Utwórz model Zamówienie

Uwaga: tutaj „konta” to nazwa mojej aplikacji

Vijay Choudhary
źródło