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

Я накопил немало миграций, используя South (0.7) и Django (1.1.2), которые начинают потреблять довольно много времени в моих модульных тестах. Я хотел бы сбросить базовый уровень и начать новый набор миграций. Я просмотрел документацию по Югу , выполнил обычный поиск Google / Stackoverflow (например, «django south (reset OR delete OR remove)») и не нашел ничего очевидного.

Один из подходов, который я рассматривал, будет включать «начало» путем «удаления» юга или «очистки» истории вручную (например, очистка таблицы db, удаление файлов миграции из директора миграции) и просто повторное выполнение,

./manage.py schemamigration southtut – начальный

Итак, если кто-то сделал это раньше и имеет несколько советов / предложений, они были бы весьма признательны.

    EDIT – я помещаю комментарий ниже в верхней части этого, так как важно прочитать его перед принятым ответом, который следует за @andybak

    @Dominique: Ваш совет относительно юзания manage.py reset опасен и может уничтожить базу данных, если в проекте есть сторонние приложения, использующие юг, как указано @thnee ниже. Поскольку в вашем ответе так много повышений, я бы очень признателен, если бы вы могли отредактировать его и добавить хотя бы предупреждение об этом или (еще лучше) изменить его, чтобы отразить подход @hobs (что так же удобно, но не влияют на другие приложения) – спасибо! – chrisv Mar 26 ’13 в 9:09

    Ниже приведен следующий ответ:

    Во-первых, ответ Южного автора :

    До тех пор, пока вы позаботитесь сделать это во всех развертываниях одновременно, не должно быть никаких проблем с этим. Лично я бы сделал:

      rm -r appname/migrations/ ./manage.py reset south ./manage.py convert_to_south appname 

    (Обратите внимание, что часть « reset south » очищает записи миграции для ВСЕХ приложений, поэтому убедитесь, что вы либо запускаете две другие строки для всех приложений, либо выборочно удаляете).

    convert_to_south в конце делает новую миграцию и подделку – применяет ее (поскольку ваша firebase database уже имеет соответствующие таблицы). Не нужно отбрасывать все таблицы приложений во время процесса.

    Вот что я делаю на моем сервере разработчика dev +, когда мне нужно избавиться от всех этих ненужных миграций dev:

    1. Убедитесь, что у нас есть одна и та же схема БД с обеих сторон
    2. удалять каждую папку миграции с обеих сторон
    3. run ./manage.py reset south (как говорится в сообщении) с обеих сторон = очищает южный стол *
    4. run ./manage.py convert_to_south с обеих сторон (подделка миграции 0001)
    5. то я могу снова начать миграцию и нажимать папки миграции на моем сервере

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

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

     rm /migrations/* python manage.py schemamigration  --initial python manage.py migrate  0001 --fake --delete-ghost-migrations 

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

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

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

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

    Использование manage.py reset south не является хорошей идеей, если у вас есть сторонние приложения, которые используют Юг, например, 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 (см. Ее ответ), мы используем более мягкий подход к предложению Южного автора (Andrew Godwin), приведенному здесь в другом месте, и мы отделяем то, что мы делаем с базой кода, от того, что мы делаем с базой данных, во время развертывания , потому что нам нужно, чтобы развертывания повторялись:

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

     # 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

    В отличие от южного авторского предложения, это НЕ УДАЛЯЕТ другие установленные приложения, использующие юг.

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

    Однажды:

     (1) find . -type d -name migrations -exec git rm -rf '{}' \; (2) find . -type d -name migrations -exec rm -rf '{}' \; (3) ./manage.py schemamigration  --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 – это мое приложение

    Давайте будем гением компьютера.