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

Question

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

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

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

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

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

Кстати, сайт написан на Pylons, если это имеет значение.

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.

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

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

Он делает то, что S.Lott предлагает в своем ответе автоматически для вас. Делает все, что легко.

Answer 4

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