Как эффективно управлять частыми изменениями схемы с помощью sqlalchemy?

Question

Я программирую веб-приложение, используя sqlalchemy. Все было гладко на первом этапе разработки, когда сайт не работал. Я мог бы легко изменить схему базы данных, просто удалив старую базу данных sqlite и создав новую с нуля.

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

Итак, давайте предположим, что у меня есть model.py в ревизии 50 и model.py в ревизии 75, описывающей схему базы данных. Между этими двумя схемами большинство изменений тривиально, например, новый столбец объявлен со значением по умолчанию, и я просто хочу добавить это значение по умолчанию к старым записям.

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

Как (или вы) будете обращаться с быстро меняющимися веб-приложениями, скажем, с одной или двумя новыми версиями рабочего кода в день?

Кстати, сайт написан на пилонах, если это что-то меняет.

Answer 1

Alembic - это новый инструмент миграции баз данных, написанный автором SQLAlchemy. Я нашел, что это намного проще в использовании, чем sqlalchemy-migrate. Он также без проблем работает с Flask-SQLAlchemy.

Автоматическое создание сценария миграции схемы из ваших моделей SQLAlchemy:

alembic revision --autogenerate -m "description of changes"

Затем примените новые изменения схемы к вашей базе данных:

alembic upgrade head

Подробнее здесь: http://readthedocs.org/docs/alembic/

Answer 2

Что мы делаем.

1. Используйте «главную версию». «Младшую версию» для идентификации ваших приложений.Основной версией является номер версии схемы.Главное число - это не какая-то случайная «достаточно новая функциональность».Это формальное объявление совместимости со схемой базы данных.

   В версиях 2.3 и 2.4 используется схема версии 2.

   В версии 3.1 используется схема версии 3.

2. Сделать версию схемы очень и очень заметной.Для SQLite это означает сохранение номера версии схемы в имени файла базы данных.Для MySQL используйте имя базы данных.

3. Написание сценариев миграции.2to3.py, 3to4.py.Эти сценарии работают в два этапа.(1) Запрос старых данных в новую структуру, создавая простые файлы CSV или JSON.(2) Загрузите новую структуру из простых файлов CSV или JSON без дальнейшей обработки.Эти извлекаемые файлы - потому что они имеют правильную структуру, быстро загружаются и могут легко использоваться как приспособления для модульного тестирования.Кроме того, у вас никогда не бывает двух открытых баз данных одновременно.Это делает сценарии немного проще.Наконец, файлы загрузки могут быть использованы для перемещения данных на другой сервер базы данных.

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

Answer 3

Использование sqlalchemy-migrate .

Он предназначен для поддержки гибкого подхода к проектированию баз данных и упрощения синхронизации баз данных для разработки и производства при необходимости изменения схемы. Это упрощает управление версиями схемы.

Думайте об этом как о контроле версий для вашей схемы базы данных. Вы фиксируете каждое изменение схемы в нем, и оно сможет идти вперед / назад по версиям схемы. Таким образом, вы можете обновить клиент, и он будет точно знать, какой набор изменений нужно применить к базе данных этого клиента.

Он делает то, что предлагает С.Лотт в своем ответе, автоматически для вас. Легко справляется с трудностями.

Answer 4

Лучший способ справиться с вашей проблемой - отразить вашу схему, а не декларативно. Я написал статью о рефлексивном подходе здесь: http://petrushev.wordpress.com/2010/06/16/reflective-approach-on-sqlalchemy-usage/ но есть и другие ресурсы по этому поводу. Таким образом, каждый раз, когда вы вносите изменения в свою схему, все, что вам нужно сделать, это перезапустить приложение, и отражение получит новые метаданные для изменений в таблицах. Это довольно быстро, и sqlalchemy делает это только один раз за процесс. Конечно, вам придется управлять изменениями отношений, которые вы делаете сами.