Обратная миграция с Джанго Югом


217

Хорошо, так что это глупо, и я уверен, что где-то что-то упустил.

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

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

Если не считать ручного редактирования таблиц БД и удаления файлов миграции, как мне откатить миграцию обратно? Я нахожу ссылки на обратную миграцию с помощью South через Google, но пока не нашел надежного примера кода.

Кто-нибудь может помочь?


хороший вопрос!!
Маршал X

Ответы:


335

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

Ваше приложение должно иметь каталог миграций, с файлами в нем, названными как

0000_initial.py
0001_added_some_fields.py
0002_added_some_more_fields.py
0003_deleted_some_stuff.py

Обычно при запуске ./manage.py migrate your_appSouth запускает все новые миграции по порядку. (Он просматривает таблицы базы данных, чтобы решить, какие из них «новые»).

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

./manage.py migrate your_app 0002

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


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

44
@mlissner Если вы действительно хотите, после отката базы данных, перейдите в папку миграций данного приложения (в приведенном выше примере your_app / migrations) и удалите нежелательную миграцию
Josh Russo

1
Точно - Юг никогда не пропускает миграции; он ожидает, что файлы из 0001-nnnn представляют собой согласованный набор миграций для любого значения nnnn. Если это не так, то вам нужно изменить порядок или удалить нарушителей самостоятельно.
Ян Клелланд,

217

На тот случай, если кто-то (как я) задумался, как перейти с первоначального (0001) :

django-admin.py migrate some_app zero

вывод:

Running migrations for some_app:
 - Migrating backwards to zero state.
 < some_app:0001_initial

«ноль» - это особое состояние перед любой миграцией.

Ссылка: http://south.aeracode.org/docs/commands.html


6
Кто-то запустил миграцию 0001 - fake, и это был единственный способ запустить 0001 в обратном направлении. Спасибо!
jmanning2k

1
Очень важный ответ, я задавался вопросом, почему migrate 0000не работает. Что касается фальшивой миграции, да, она может вам понадобиться, если вам, например, нужно только отменить (возможно, неправильную) первоначальную миграцию, но история миграции считает, что эта миграция никогда не происходила.
Томаш Гандор

3

Добавьте имя миграции в конце параметров:

./manage.py migrate app-name 00xx-migration-name

2
Это нормально, и я делал это раньше, но это много печатать / вставлять. Голого «государственного» числа - в данном случае 00xx- достаточно. При улучшении и тестировании миграции вы можете иметь обе команды в истории: вперед (без аргументов), назад с предыдущим номером состояния.
Томаш Гандор
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.