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

Ответ 1

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

@Dominique: Ваш совет относительно manage.py reset на юге опасен   и может уничтожить базу данных, если есть сторонние приложения, использующие   юг в проекте, как указано ниже @thnee. Поскольку ваши   ответ имеет так много upvotes, я бы очень признателен, если бы вы могли редактировать   это и добавить хотя бы предупреждение об этом, или (еще лучше) изменить его   для отражения подхода @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 в конце делает новую миграцию и подделку - применяет ее (поскольку ваша база данных уже имеет соответствующие таблицы). В этом процессе нет необходимости отбрасывать все таблицы приложений.

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

reset south удалит всю историю переноса для всех установленных приложений.

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

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

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

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. Fake выполнить начальные миграции для моих приложений

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

$ ./manage.py migrate --fake my_app

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

Ответ 4

Как и 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

Ответ 5

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

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

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

Ответ 6

Следующее - только если вы хотите reset все приложения. Перед этой работой создайте резервную копию всех ваших баз данных. Также обратите внимание на 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 <APP_NAME> --initial
(4) [GIT COMMIT]

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

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

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

Ответ 7

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

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

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

wiki -is мое приложение