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

Question

У меня есть существующее веб-приложение django, которое используется. Мне нужно радикально перенести одну ключевую модель в моем проекте на совершенно новый дизайн, но я хочу кэшировать все существующие данные для этой модели и перенести их в новые записи в рабочем состоянии, когда они будут готовы к развертыванию.

Я могу позволить себе отключить свой веб-сайт на несколько часов за одну ночь и сделать все, что мне нужно для миграции. Каковы некоторые разумные способы, которыми я могу сделать эту миграцию?

Кажется, любая миграция должна: 1) Дамп всех существующих данных в некоторый формат, такой как SQL, JSON, XML 2) Миграция модели в новый формат 3) Перезагрузите данные в новую модель, используя скрипт конвертации

Я также подумал о том, чтобы попытаться сохранить все существующие данные в какой-то другой модели, называемой «OldModel» (если Model - это имя существующей модели), а затем перенести данные в реальном времени.

Answer 1

Есть проект, который поможет с миграциями, о которых я слышал: Юг .

Сказав это, я признаю, что мы не использовали его. Мы все еще планируем наши миграции, используя файл операторов SQL. Безумие, я знаю, но у него есть преимущество тестируемости. Вы можете запускать его столько раз, сколько необходимо во время разработки и промежуточного тестирования перед «большим развертыванием». Он может быть управляемым источником, разнесенным и т. Д. Поэтому он также может вызываться из более крупного сценария развертывания. Конечно, мы запускаем производство перед его запуском: -)

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

Эксперименты, которые мы проводили с JSON, XML и дампами в стиле "OldModel" -> "NewModel", масштабировались довольно плохо. Имейте в виду, YMMV ... у нас есть довольно большая база данных. С помощью сценария вы можете работать с производственной базой данных без необходимости выгружать или перезагружать большие объемы данных. Таким образом, даже сложная миграция может занять несколько секунд, а не часов.

Answer 2

Выполните все миграции поэтапно!

Если вам нужно добавить поле, добавьте его со значением по умолчанию или необязательно. Это безопасно. Если вам нужно сделать существующее необязательное поле обязательным, сначала укажите его по умолчанию. Если вам нужно, чтобы существующее поле со значением по умолчанию не имело значения по умолчанию, удалите значение по умолчанию после исправления всего кода, который создает экземпляры. Если вам нужно изменить тип поля, сначала добавьте новое поле, которое наследует значение от текущего. Затем запустите сценарий, чтобы обновить существующие экземпляры, чтобы заполнить новое поле. В-третьих, удалите весь код, который использует старое поле, чтобы использовать новое. Наконец, если исходный код не оставлен, вы можете удалить его.

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

Answer 3

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

Далее см. S. Lott's answer to на этот вопрос о рабочих процессах миграции за отличную идею об использовании номеров версий в имени модели для упрощения миграции, включая структурирование автономного сценария для правильного преобразования таблиц , На мой взгляд, это значительно превосходит по сравнению с сериализацией данных для экспорта и последующей попыткой построить новые таблицы путем импорта.

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

Answer 4

Если вам удобнее с Django ORM, чем с необработанным SQL, вы можете рассмотреть возможность использования Model -> BackupModel -> TestModel -> Model, где все, кроме последнего шага, могут выполняться без удаления данных.

def backup(InModel,OutModel):
    in_objs = InModel.objects.all()
    for obj in in_objs:
        out_obj = OutModel.convert_from(InModel,obj)
        out_obj.save()

Здесь вы просто должны убедиться, что во всех ваших моделях реализованы методы convert_from. Все они должны быть тривиальными преобразованиями, за исключением BackupModel -> TestModel. В других случаях ничего, кроме класса, не изменилось бы, все данные были сохранены одинаково.

Преимущество этого состоит в том, что перед тем, как вы переписываете все свои интерфейсы, вы можете поиграть с TestModel и убедиться, что ваши преобразования были такими, как вы думали. Если все идет не так, вы конвертируете из BackupModel-> Model, и все в порядке. В худшем случае вы отказываетесь от ORM в Django, запускаете обратно в SQL и просто переименовываете все таблицы, которые начинаются с backupmodel __ *, в модель __ * в вашей базе данных.

Отказ от ответственности: я никогда не делал этого.