Стоит ли использовать sqlalchemy-migrate? [закрытый]

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

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

Но хуже всего то, что "manage.py Тест " команда. Мало того, что он на самом деле изменяет базу данных (Этот пункт четко указан в документации, поэтому я не могу винить миграцию), но мой первый сценарий миграции просто сделал простой глупый перенос схемы, оставив обновленную-пониженную БД с другая схема, чем исходная . Но ... manage.py тест " просто ответил что-то вроде

 success !
То есть он даже не проверял, была ли схема оставлена в когерентном состоянии. Так стоит ли использовать migrate?Есть ли какое-либо преимущество по сравнению с методом Do It Yourself, связанным с надлежащей практикой , предложенным С. Лоттом ? Существуют ли альтернативы sqlalchemy-migrate, фактически упрощающие процесс миграции, или я просто пытаюсь использовать migrate с плохим a priori (тогда, пожалуйста, покажите мне, почему это явно не превосходит создание столбцов CSV, как предложено в ссылке выше)?

Большое Спасибо!

3 40
python sqlalchemy migration data-migration

3 ответа:

Вместо этого используйте перегонный куб:

Http://pypi.python.org/pypi/alembic

Спасибо за комментарии, отредактировано, чтобы добавить некоторые рассуждения --

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

Автогенерация: не только ее режим работы, но если вы выберете, Alembic прочитает конфигурацию sqlalchemy вашего приложения (например, ваши декларативные классы моделей, которые настраивают все ваши таблицы, ограничения и сопоставления) и сравнит с фактическим текущим состоянием вашей базы данных, а также выведет скрипт Python, представляющий дельту между ними. Затем вы передаете этот сценарий команде обновления перегонного куба, и там вы идете, различия устраняются. Небольшой объем редактирования сценария переноса вручную составляет обычно это необходимо, и это (а) просто природа миграции, и (Б) то, что вы хотите сделать в любом случае, чтобы убедиться, что вы были полностью осведомлены о точных шагах, которые миграция собирается выполнить, прежде чем вы запустите ее.

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

Перегонный куб вышел ( http://pypi.python.org/pypi/alembic ) и поддерживается автором SQLAlchemy и учитывая тот факт, что разработка SQLAlchemy-migrate выглядит застопорившейся, практически без коммитов в этом году ( http://code.google.com/p/sqlalchemy-migrate/source/list ), я думаю, что его больше не стоит использовать , я переключу свой текущий проект на перегонный куб.

Если бы он все еще сильно поддерживался, я был бы уверен в способности проекта сохранить синхронизировано с SQLAlchemy ( что было и раньше).

7

Лично мне нравится им пользоваться. Это здорово, потому что новые установки (dev, test, prod) могут быть загружены очень легко. И не только это, но он обеспечивает дом для приложения по мере его роста и обеспечивает хорошие точки входа для тех миграций, которые должны происходить по мере перехода от версии к версии вашего приложения. Что-то должно выполнить alter/etc на серверах разработки, тестирования и производства.

Она совершенна? Нет. Вы можете оставить свой БД в плохом состоянии, но именно поэтому у вас есть разработка/тестирование / производство версий вещей.

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

3