Django 1.7 - makemigracje nie wykrywają zmian

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.

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.

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

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)

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.

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.

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

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

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.

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.

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

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.

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

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

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.

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.

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

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

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

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

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.

Może to komuś pomoże.

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

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

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

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.

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 tę „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 !

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

python manage.py migrate --fake-initial

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.

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

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!

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