Можно ли запускать скрипты подключаемого модуля миграции базы данных вне проекта Grails?

Я использовал плагин миграции базы данных Grails во время разработки своего приложения, и очень нравится его функционал. (Grails 1.3.7, миграция базы данных 1.0)

Проблема: я ограничен тем, что все развертывания должны происходить через пакеты Debian, содержащие мое приложение. Его установит другая группа, компетентные админы, но не программисты в полном смысле этого слова. Таким образом, я не могу перенести схему базы данных, как указано в типичных сценариях рабочего процесса.

Вопрос: Какие скрипты/классы/??? мне нужно связать или зависеть от пакета, чтобы иметь возможность выполнять команды:

grails -Dgrails.env=$TARGET dbm-update

и

grails -Dgrails.env=$TARGET dbm-changelog-sync

и

grails -Dgrails.env=$PROD dbm-diff $PROMOTION_ENV

из моего сценария debian/postinst?

Я пытался установить Grails, сделать подключаемый модуль миграции базы данных зависимым от времени выполнения и включить сценарии Dbm*... но безуспешно. Самое близкое, что я нашел, это то, что Grails жалуется, что я не в корне приложения Grails, когда я пытаюсь запустить один из сценариев.

Можно ли это сделать, или кто-нибудь может предложить хорошую альтернативу, которая, надеюсь, не заставит меня изучать совершенно новую метафору миграции?


debian grails database-migration
person JohnKeller    schedule 30.08.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Эти три сценария являются оболочками для соответствующих действий Liquibase. Существуют некоторые скрипты, специфичные для Grails, например. dbm-gorm-diff, который создает журнал изменений между вашим кодом и базой данных, но это сценарий разработчика, который здесь не применяется.

Так что я бы пошел с прямым Liquibase. Вызовы более подробные, так как вам нужно указать информацию о подключении в командной строке (в Grails я могу получить ее из источника данных для вас), но это должно быть легко написать в сценарии. Все, что вам нужно, это jar-файл Liquibase в пути к классам, и его также можно легко добавить в сценарии.

Другим недостатком является то, что вы будете работать в традиционном Liquibase XML вместо сценариев миграции на основе Groovy, поэтому нет циклов, проверок if/then и т. д. Но пока у вас есть довольно стандартные миграции для запуска, все должно быть в порядке. .

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

person Burt Beckwith    schedule 30.08.2011
comment
Спасибо за быстрый ответ! Я пытаюсь избежать неожиданного поведения, вызванного наивным переносом моей схемы, если администратор по какой-то причине изменил рабочую схему (мониторинг/аудит). Я хочу, по крайней мере, сравнить то, что будет после миграции, с тем, что есть на самом деле после миграции, и предоставить администратору осознанный выбор. Я думаю, что я мог бы использовать журнал изменений XML, созданный сервером сборки (с использованием плагина) непосредственно перед упаковкой, а затем из моего сценария установки использовать liquibase для его выполнения. Вот что я попробую, основываясь на ваших отзывах - еще раз, спасибо - person JohnKeller; 30.08.2011