Как должен работать откат с Югом?

Question

Цвет меня смутил. Давайте предположим, что у нас есть проект Django с южными миграциями. В настоящее время версия производственного проекта A, версия в разработке B. Теперь предположим, что версия B установлена ​​в производство:

1. Установить новый код
2. Пробег ./manage.py syncdb && ./manage.py migrate
3. Перезагрузите веб-сервер и будьте счастливы.

Следующее предположение: версия B вообще не работает. Он был в разработке, но не в производстве, поэтому его необходимо откатить. И здесь я должен что-то упустить. Я вижу две возможности:

1. Старый код переустановлен. Теперь целесообразна обратная миграция на юг, однако это невозможно, поскольку старый код не содержит всех новейших миграций, необходимых для возврата.
2. Сначала откатим изменения базы данных, а затем переустановим старый код. Однако как мы узнаем, какая миграция является последней для версии A? Поскольку в одном проекте можно легко сосчитать пару десятков приложений, вам необходимо выяснить для каждого из них, какой стенд миграции относится к старой версии, затем перенести каждое приложение отдельно, а затем выполнить откат кода и надеяться на лучшее.

В обоих случаях мне не хватает важной информации: либо код миграции в первом случае, либо отношение «миграция <-> версия» во втором. Что мне здесь не хватает?

PS : Да, я знаю, что могу восстановить базу данных из резервной копии, это то, что я на самом деле делаю. Я хочу знать, как вся эта теория миграции баз данных сочетается с откатами.

Answer 1

OK. Я полагаю, вы работаете с контролем версий? Сейчас очень важно определить, из чего состоят «А» и «В». Если мы махаем рукой / предполагаем, что этот аморфный кусок кода, на который мы ссылаемся, - это «A», а эта другая неопределенно определенная вещь, которую мы все помечаем как «B» - это не сработает.

Если вы пытаетесь переустановить «A» вместо «B», у вас есть два варианта: 1) извлечение и восстановление «А» с нуля (синхронизация и миграция) 2) верните «B» обратно к «A».

1) Вероятно, не будет работать, потому что вы не можете позволить себе убивать данные в БД, чтобы синхронизировать их из ничего 2) Включает миграции. Во-первых, вы должны найти миграции в «B», а не в «A». На юге все миграции для каждого приложения пронумерованы (0001, 0002, 0003 и т. Д.). Итак, предположим, что «B» находится в 050, а «A» в 0031. Пока вы извлекли «B», запустите python manage.py migrate appname 0031, что отменит все изменения в БД, которые вы сделали для «B». Затем в вашей системе контроля версий вы извлекаете 'A' (является ли 'A' просто коммитом, тэгом или веткой)

К сожалению, вы не можете откатиться до «А» и затем сказать «не мигрировать все, чего у вас нет». Это было бы более простым решением, но тогда вам понадобится ваша миграционная система, чтобы узнать о вашей системе контроля версий, и это немного сложно.

Answer 2

Не уверен, что это был вариант в вашем случае, но не могли ли вы запустить обратную миграцию в рабочей среде до , когда вы переместили свой код обратно в версию 'A'? Таким образом, ваш БД возвращается к тому, что происходило до того, как вы сделали syncdb, и затем вы изменили код на версию А, и вы вернулись к тому, с чего начали.