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

Question

Я использовал плагин для миграции базы данных 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, когда пытаюсь запустить один из сценариев.

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

Answer 1

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

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

Еще один недостаток заключается в том, что вы будете работать с традиционным XML Liquibase вместо сценариев миграции на основе Groovy., так что нет циклов, если / затем проверяет и т. д. Но если у вас достаточно стандартные миграции для запуска, все будет в порядке.

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