Jakie jest zalecane podejście do resetowania historii migracji przy użyciu Django South?

Jeśli potrzebujesz selektywnie (tylko dla jednej aplikacji) zresetować migracje, które trwają zbyt długo, to zadziałało dla mnie.

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

Nie zapomnij ręcznie przywrócić zależności w innych aplikacjach, dodając linie takie jak depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) do pliku <app-dir>/migrations/0001_initial.py, jako pierwszy atrybut w klasie migracji tuż poniżej class Migration(SchemaMigration):.

Można wtedy ./manage.py migrate <app-name> --fake --delete-ghost-migrations w innych środowiskach, na to więc odpowiedź . Oczywiście jeśli sfałszujesz delete lub sfałszujesz migrate zero, będziesz musiał ręcznie usunąć wszelkie pozostałe tabele db z migracją typu this .

Bardziej jądrową opcją jest ./manage.py migrate --fake --delete-ghost-migrations na serwerze wdrażania na żywo, a następnie [my]sqldump. Następnie przenieś ten zrzut do [my]sql w środowiskach, w których potrzebujesz zmigrowanego, w pełni wypełnionego db. South sacrilege, wiem, ale zadziałało na mnie.

Dzięki odpowiedziom Dominique ' a Guardioli i grzejników kuchennych, pomogło mi rozwiązać trudny problem. Jednak jest kilka problemów z rozwiązaniem, oto moje podejście do niego.

Używanie manage.py reset south jest nie jest dobrym pomysłem , jeśli masz aplikacje innych firm , które używają South, na przykład django-cms (W zasadzie wszystko używa South).

reset south usunie całą historię migracji dla wszystkich zainstalowanych aplikacji.

Teraz rozważ, że uaktualnisz do najnowszej wersja django-cms, będzie zawierać nowe migracje, takie jak 0009_do_something.py. Południe z pewnością będzie zdezorientowane, gdy spróbujesz przeprowadzić tę migrację bez 0001 przez 0008 w historii migracji.

Przede wszystkim upewnij się, że Twoje aplikacje nie mają żadnej desynchronizacji między migracjami na dysku a migracjami wykonanymi w bazie danych. W przeciwnym razie będzie ból głowy.

1. Usuń historię migracji dla moich aplikacji]}

sql> delete from south_migrationhistory where app_name = 'my_app';

2. Usuń migracje Dla Moich aplikacji]}

$ rm -rf my_app/migrations/

3. Tworzenie nowych początkowych migracji dla aplikacji my apps]}

$ ./manage.py schemamigration --initial my_app

4. Fałszywe wykonywanie początkowych migracji dla moich aplikacji

Wstawia migracje do south_migrationhistory bez dotykania rzeczywistych tabel:

$ ./manage.py migrate --fake my_app

Krok 3 i 4 to właściwie tylko dłuższy wariant manage.py convert_to_south my_app, ale wolę tę dodatkową kontrolę, w tak delikatnej sytuacji, jak modyfikowanie baza danych produkcji.

Podobnie jak thnee (zobacz jej odpowiedź), używamy łagodniejszego podejścia do sugestii autora południa (Andrew Godwin) cytowanej gdzie indziej tutaj i oddzielamy to, co robimy z bazą kodu od tego, co robimy z bazą danych, podczas wdrażania, ponieważ potrzebujemy, aby wdrożenia były powtarzalne: {]}

Co robimy w kodzie:

# Remove all the migrations from the app
$ rm -fR appname/migrations
# Make the first migration (don't touch the database)
$ ./manage.py schemamigration appname --initial

Co robimy z bazą danych po wdrożeniu kodu

# Fake the migration history, wiping out the rest
$ ./manage.py migrate appname --fake --delete-ghost-migrations

Jeśli tylko pracujesz na maszynie dev, napisałem polecenie zarządzania, które robi prawie to, co sugerował Dominique.

Http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

W przeciwieństwie do sugestii autora south, nie zaszkodzi to innym zainstalowanym aplikacjom używającym south.

Następujące jest tylko, jeśli chcesz zresetować wszystkie aplikacje. Proszę wykonać kopię zapasową wszystkich baz danych przed wykonaniem tej pracy. Zanotuj również depends_on w plikach początkowych, jeśli istnieją.

Raz:

(1) find . -type d -name migrations -exec git rm -rf '{}' \;
(2) find . -type d -name migrations -exec rm -rf '{}' \;
(3) ./manage.py schemamigration <APP_NAME> --initial
(4) [GIT COMMIT]

Przetestuj bootstrapowanie projektu przed wypchnięciem. Następnie, dla każdej lokalnej/zdalnej maszyny, zastosuj następujące:

(5) [GIT PULL]
(6) ./manage.py reset south
(7) ./manage.py migrate --fake

Wykonaj initial (3) dla każdej aplikacji, którą chcesz ponownie włączyć. Należy pamiętać, że reset (6) usunie tylko historię migracji, dlatego nie będzie szkodliwy dla bibliotek. Fałszywe migracje (7) przywrócą historię migracji wszystkich zainstalowanych aplikacji innych firm.

Usuń niezbędny plik z folderu aplikacji

Przykładowa ścieżka

 cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations

Wiki - is my app