Мы успешно перенесли приложение Django 1.4 на Django 1.8. Версия приложения Django 1.4 все еще используется в производстве, пока мы не выпустим Django 1.8. Проблема в том, что на рабочем сервере было обновлено много данных, которые необходимо перенести на версию 1.8. Есть ли способ перенести данные из базы данных 1.4 в 1.8, кроме как вручную? Обратите внимание, что столбцы модели/базы данных различаются в обеих версиях.
Может кто подскажет хорошие варианты?
Спасибо.
Обязательно к прочтению
Миграции Django: https://docs.djangoproject.com/en/1.8/ref/django-admin/#makemigrations-app-label
Предполагая, что вы используете Юг: https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south
Начало работы
Сначала создайте дамп вашей локальной базы данных. Я предпочитаю использовать для этого mysql/postgres/whatever docs, а не использовать ./manage.py dumpdata.
Вы также захотите сбросить свою производственную базу данных только для сохранности.
Затем в вашей локальной среде я бы сбросил базу данных и создал новую базу данных.
Затем я бы проверил, что все ваши миграции действительно работают с пустой базой данных. Это инструкции для django 1.8.
./manage.py makemirgrations
./manage.py migrate
Это поможет обнаружить, если какие-либо миграции находятся в несогласованном состоянии, работая с чистого листа. Если вы столкнулись с какими-либо ошибками, их следует исправить в первую очередь.
Учитывая, что это работает, теперь я бы проверил, действительно ли ваши миграции работают с вашими производственными данными.
Поэтому удалите свою локальную базу данных, создайте новую, а затем загрузите производственный дамп.
Если таблицы уже настроены правильно (т. е. они находятся в актуальном состоянии в вашей производственной базе данных), вам нужно будет подделать все миграции.
./manage.py migrate --fake <appname>
Однако, учитывая, что вы изменили некоторые модели после обновления до версии 1.8 в вашей локальной среде, вам может потребоваться подделать только некоторые миграции. Это может быть сложной частью в зависимости от времени обновления и создания миграции.
Поскольку django 1.7 просто создаст первоначальную миграцию для каждого приложения, вам может потребоваться разбить миграцию для некоторых приложений. То есть вместо 0001_initial вам может потребоваться вручную разбить эту миграцию на 2 компонента: 1. миграцию для соответствия текущему состоянию вашей производственной базы данных 2. миграцию для соответствия любым дополнительным изменениям, которые вы внесли в свою модель с тех пор.
Один из способов сделать это — проверить свой первый коммит после того, как django 1.8 работает правильно локально, а затем запустить
./manage.py makemigrations
затем совершить это
затем перейдите к своему последнему коммиту, затем запустите
./manage.py makemigrations
Теперь у вас должно быть 2+ миграции в каждом приложении, которое вы изменили после обновления до django 1.8.
Затем вы можете подделать инициалы для тех приложений, у которых есть 2+ новых миграции для django 1.8.
./manage.py migrate --fake-initial app1 app2
а остальное просто
./manage.py migrate app3 app4
Теперь запустите тесты, чтобы убедиться, что все работает локально.
Если вы изменили миграции, вы снова захотите протестировать локально с пустой базой данных, чтобы убедиться, что они работают гладко.
Как только это сработает, запишите команды «миграции», которые вы использовали, а затем разверните свое приложение в рабочей среде и запустите только эти команды миграции после обновления до django 1.8 на своем сервере.
После успешного завершения
Я уверен, что в приведенном выше есть пара пробелов, но, надеюсь, это дает вам суть того, что вам нужно делать.
