Phing + DbDeploy, откат к предыдущей ревизии?

Question

[sapp]

Стоит задача настроить более-менее автоматизированное версионирование для баз данных (MySQL) на веб-проектах. Для кода используется Mercurial. С базами долго гуглил и пришёл к варианту Phing+DbDeploy.

Теперь возникла проблема. Настроил Phing+DbDeploy по оригиналу этой статьи: habrahabr.ru/post/63585/
Но статья не покрывает собственно использования undo-функционала. То есть, при такой настройке просто нет способа автоматизированно откатиться к какой-либо из предыдущих ревизий базы.

Усердное гугление решений не дало результатов. Решал ли кто-то эту задачу? Может быть, какие-то хорошие альтернативы Phing и DbDeploy есть? Держу на примете Liquibase, но пока останавливает то, что он требует явы.

Жажду ваших советов, друзья!

Answer 1

[Алексей Журбицкий]

Скорее всего придется писать вспомогательный скрипт на удобном для вас языке.
У вас все данные для этого есть: таблица changelog и файлы в папке deltas.
Все что нужно — это сравнить эти два списка (задача вспомогательного скрипта), для разницы выполнить задание dbdeploy и затем exec и выполнением суммарного undo скрипта.

Comments

[sapp]

Ну я вот примерно так и вижу решение проблемы. Вот только вопрос — неужели никто не решал этой проблемы? Я почему-то не нагуглил ничего готового на эту тему. В то время, как Phing+DbDeploy позиционируются как решение для версионирования БД, а версионирование подразумевает не только продвижение вперёд, но и откаты. Вот что для меня странно.

[sapp]

Может есть какое-то иное толковое решение, покрывающее эти все моменты? Ведь велосипедить тоже не хочется.

[Алексей Журбицкий]

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

Answer 2

[daeto]

Хм… Может, в вашем случае будет достаточно добавить в таск полный дамп БД перед выкатом новой версии и восстановление её из дампа при откате? Или БД очень напряжённо используется и потеря данных за время, требующееся для проверки, критична?

Если же очень хочется версионировать схему БД, то лучше это делать при помощи полноценных миграций (c up() и down()) вместо дельт в одну сторону. Есть разные библиотеки для этого, в зависимости от используемых технологий вам может лучше подойти та или иная. Или просто сделать по аналогии с описанным, но файлы и для up, и для down.

Comments

[sapp]

Дело в том, что дельты в описанном случае уже не односторонние сами по себе. В них заложен функционал «undo». И dbdeploy, насколько я понимаю, способен эти undo выполнять. Вопрос вот в том, как его грамотно инструктировать это делать более-менее автоматизированно.

[sapp]

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

[Алексей Журбицкий]

sapp на самом деле dbdeploy только формирует undo файл (атрибут undooutputfile), а дальше вы сами должны решить что с ним делать.