Grailsにpre-GORM initフックがありますか？

Question

私はGrails 2.5.xアプリケーションの非常に特殊な要件に取り組もうとしています。データベースのスキーマをアップグレードする前に、アプリケーションの開始前に一連のデータベース変換スクリプト（DBのバージョン/アプリケーションのバージョン）。私たちはこれまで「伝統的な」Java Servletアプリケーションでこれを行っていましたが、Grailsと少し面倒です。

質問：イベントは、私は何とか私はGroovyと既存のデータソース構成を使用することができるようになるアプリの起動時ににフックができ、まだGORM/Hibernateが起動する前に起こるであろうと、Grailsのでは、ありますか？

一部のオプションは、私はすでに確認されました：

• ブートストラップのinitクロージャは、データベーススキーマの期限が切れた場合、アプリケーションは単に「検証」モードで起動しないと同じように、ここでは動作しません。
• これまで使用していなかったEvents.groovyがありますが、これらのイベントは、WARファイルにパッケージ化され、アプリケーションコンテナにデプロイされた自己完結型アプリケーションではなく、grailsのコンパイル/ビルドライフサイクルを目的としています。
• grails database-migrationプラグインは似ていると思われ、ターゲットサーバでGrailsのコマンドラインを利用できると期待しています。と、変換は管理者によって手動で実行されます。 私はここで間違っている可能性が高いと判明しました。

Answer 1

私は本当にGORMの起動が行われる（とデータベースの検証や作成を実行）ブートストラップは、単にinitを介して、カスタムデータベースの移行コードを実行するための方法があるの前に、Grailsの起動時にフックする方法を発見していないもののHibernateのすべてのhbm2ddlを無効にする（有効なdbCreate値のいずれかを省略する）。

私たちのプロジェクトではデータベース移行プラグインが使用されましたが、すぐに正しく動作するように、hhm2ddlも無効にする必要があります。 validateオプションを使用した場合、GORMはの有効性を確認してからデータベース移行が行われ、アプリケーションは起動しませんでした。

hbm2ddlを無効にすると、hibernateのデータベーススキーマ検証に干渉することなく実行できるように、データベースのアップグレード/移行コードのカスタム実装を提供する場合も同じアプローチが使用できます。明らかな欠点は、検証モードをもはや使用できないことである。