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

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

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

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

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

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

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

Ответ 1

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

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

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

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

alembic upgrade head

Дополнительная информация здесь: http://readthedocs.org/docs/alembic/

Ответ 2

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

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

В версиях 2.3 и 2.4 используются две версии схемы.

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

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

Ответ 3

Используйте sqlalchemy-migrate.

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

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

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

Ответ 4

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