Миграция Django-CMS 2.4.3 на Django-CMS 3.1.1

Question

У меня есть несколько приложений django-cms 2.4.3 (django 1.5.5), работающих в процессе производства. Я в процессе обновления до django-cms 3.1.1 (Django 1.8/python2.7). Я могу запустить тестовую среду без проблем. Тем не менее, импорт моих существующих данных был проблемой. Я пробовал:

1. 'python manage.py dumpdata> dump.json' на рабочем сервере.
2. 'python manage.py loaddata -ignorenonexistent dump.json' на сервере разработки.

В результате серии таблиц уже существует, нарушает нулевой Ограничить, столбец не существует, и т.д ...

Затем я попробовал экспорт непосредственно из PostgreSQL (в качестве резервного) и восстановление в развитие установить. Запустите python manage.py migrate. Получите ряд дополнительных ошибок, похожих на выше. Прогон мигрирует с помощью migrate -fake-initial и -fake. Проблема в том, что многие страницы (в качестве примера сосредоточились на cms_page) изменили поля в 3.x с 2.4. Миграция будет рассматривать только изменения в миграции, разницу в таблице. Некоторые поля были добавлены, некоторые были удалены. Я просмотрел файл 0001 миграции cms_page. Он создает таблицу страниц с дополнительными столбцами. Миграция 0003 добавляет больше полей и некоторые капли. У этого списка нет конца.

Я потратил более трех дней, пытаясь перенести мои существующие данные. Я даже начал с django-cms 3.0, поместив некоторые плагины, автоматически обновил мою среду разработки до 3.1 (нет, я не включил pip install --upgrade). Просто разочарование.

Я даже начал вручную обновлять таблицы базы данных. Настольные ограничения делают это практически невозможным. Теперь я рассматриваю полностью переписывание миграции django-cms. Есть ли что-то, что я вижу, что облегчит миграцию данных? Может быть, остаться с django-cms 2.4 и обновить django до поддерживаемой версии?

Answer 1

Если я не понял, что вы делаете, я не думаю, что вы делаете это правильно.

У вас не должно быть проблем с миграцией; они разработаны специально для того, чтобы упростить то, что вы делаете (модернизация изменений в базе данных).

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

Что должно работать:

1) Сделать копию существующего производства 2.4.3 сайта - код, базы данных и все. Не трогайте вещь на самой производственной площадке, если она работает. Отныне работайте только над копией.

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

Для каждой миграции в каталоге миграции вы должны иметь запись в таблице миграции в базе данных. Если нет, но вы уверены, что ваша база данных обновлена ​​с кодом модели, вы можете запустить migrate --fake, чтобы отметить эти миграции как запущенные.

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

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

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

4) Теперь приступите к обновлению программного обеспечения, по возможности, по одному компоненту и запустите `` migrate`. Используйте django CMS release notes, чтобы помочь вам понять, что меняется, что еще нужно изменить с ним и любые другие шаги, которые вам нужно предпринять.

Проверьте, прошел ли какой-либо компонент, что все хорошо.

5) Вам также нужно будет обновить Django; используйте примечания к выпуску, чтобы определить, когда вы должны обновить Django, прежде чем продолжить следующее обновление CMS django.