Каков рекомендуемый подход к сбросу истории миграции с помощью Django South?

Если вам нужно выборочно (только для одного приложения) сбросить миграции, которые занимают слишком много времени,этой работал для меня.

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

Не забудьте вручную восстановить все зависимости в других приложениях, добавляя строки, такие как depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) на <app-dir>/migrations/0001_initial.py файл, как первый атрибут в вашем классе миграции чуть ниже class Migration(SchemaMigration):.

можно тут ./manage.py migrate <app-name> --fake --delete-ghost-migrations в других средах, per это так ответ. Конечно, если вы подделать удаление или подделать migrate zero вам нужно вручную удалить все оставшиеся таблицы БД с миграцией, такой как этой.

более ядерный вариант ./manage.py migrate --fake --delete-ghost-migrations на сервере живого развертывания, за которым следует [my]sqldump. Затем передайте этот дамп в [my]sql в средах, где вам нужна перенесенная, полностью заполненная БД. Южное святотатство, я знаю, но работало на меня.

благодаря ответам Доминика Гвардиолы и hobs, это помогло мне решить сложную проблему. Однако есть несколько проблем с решением, вот мой взгляд на это.

используя manage.py reset south is не очень хорошая идея если у вас есть какие-либо сторонние приложения который использует юг, например django-cms (в основном все используют на юге).

reset south будет удалить всю историю миграции для всех приложений, которые вы установили.

теперь считайте, что вы обновляете до последней версии django-cms, он будет содержать новые миграции, такие как 0009_do_something.py. Юг, несомненно, будет смущен, когда вы попытаетесь запустить эту миграцию, не имея 0001 через 0008 в истории миграции.

гораздо лучше/безопаснее выборочно сбрасывать только приложения, которые вы поддерживаете.

прежде всего, убедитесь, что ваши приложения не имеют никакой десинхронизации между миграциями на диске и миграциями которые были выполнены в базе данных. Иначе будет головная боль.

1. Удалить историю миграции для моих приложений

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

2. Удалить миграции для моих приложений

$ rm -rf my_app/migrations/

3. Создайте новые начальные миграции для моих приложений

$ ./manage.py schemamigration --initial my_app

4. Поддельные выполнить первоначальные миграции для моих приложений

это вставляет миграции в south_migrationhistory не касаясь фактических таблиц:

$ ./manage.py migrate --fake my_app

Шаг 3 и 4 на самом деле просто более длинный вариант manage.py convert_to_south my_app, но я предпочитаю этот дополнительный контроль в такой деликатной ситуации, как изменение производственной базы данных.

Как и thnee (см. Ее ответ), мы используем более мягкий подход к предложению Южного автора (Эндрю Годвина), приведенному в другом месте здесь, и мы отделяем то, что мы делаем с базой кода, от того, что мы делаем с базой данных во время развертывания, потому что нам нужно, чтобы развертывания были повторяемыми:

что мы делаем в коде:

# 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

что мы делаем с базой данных после развертывания этого кода

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

Если вы просто работаете на машине dev, я написал команду управления, которая делает в значительной степени то, что предложил Доминик.

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

в отличие от предложения Южного автора, это не повредит другим установленным приложениям, использующим юг.

ниже только если вы хотите восстановить все приложения. Пожалуйста, сделайте резервную копию всех ваших баз данных до этой работы. Также запишите свой depends_on в исходных файлах, если они есть.

на этот раз:

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

Проверьте загрузку вашего проекта перед нажатием. Затем для каждой локальной/удаленной машины примените следующее:

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

сделать начальный (3) для каждое приложение вы хотите повторно вовлечь. Обратите внимание, что reset (6) удалит только миграцию история, поэтому не вредна для библиотек. Поддельные миграции (7) вернут историю миграции любых установленных сторонних приложений.

удалить необходимый файл из папки приложения

путь к экземпляру

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

wiki-это мое приложение