2013-12-20 8 views
5

私はGrails 2.xでモジュール式アプリケーションを開発しており、すべてのプラグイン/モジュールがgrails-appで独自の移行をホストするようにデータベース移行を構成したいと思います/ migrationsフォルダに移動します。 (すべての移行を作成アプリケーションプロジェクトの移行フォルダに入れるのとは対照的に)アプリケーションの変更履歴にGrailsプラグインの移行を含める

作成アプリケーションプロジェクト自体は通常、プラグインに格納されているのでマイグレーションはありません。

アプリケーションプロジェクトに「マスター」チェンジログを作成し、プラグイン移行ファイルのみを適切な順序で参照できますか?このようにして、プラグインの依存関係の問題を処理する非常にきれいで移行しやすいシステムを作成することもできます(プラグインの依存関係を尊重する順序でプラグインの移行ファイルを配置します。 )。

デフォルトでは、Database Migrationsプラグインはプラグインの移行(私の場合はインラインプラグイン)をまったく確認/実行していないようです。ドキュメントではこのシナリオについては何も言及していませんが、モジュール化されていない簡単な開発ワークフローに集中しています。

私はDB Migrationsプラグインの問題を解決しましたが、これはアプリのマイグレーションディレクトリの外でマイグレーションファイルを実行することを許可していますが、それは非常にエレガントではない相対/絶対パスのハードコーディングを使用すると仮定します。

もっとも洗練されたソリューションは、マイグレーションの「include」ステートメントごとにプラグインを指定できれば、私のマスターチェンジログはこのようになります。

databaseChangeLog = { 
    include plugin:'core'  ,file:'000-initial.groovy' 
    include plugin:'accounting' ,file:'000-initial.groovy' 
    include plugin:'core'  ,file:'001-drop-constr-XXX.groovy' 
    include plugin:'accounting' ,file:'001-add-col-yyy-to-posting-table.groovy' 
} 

現在のDatabase Migrations Pluginと同様の機能を実装できますか?

ご意見・ご感想はありがとうございます。

答えて

3

Grailsの移行プラグインは、より良いモジュラープロジェクトをサポートするまで、私は以下のソリューションを働いてきた:

開発中は、プラグイン関連の移行を/保管プラグインの「移行」フォルダ内に開発され、問題になっているとして命名されています(例:000-initial.groovy)。

各移行はプラグインにそれを関連するパッケージ定義が含まれています

package core 

移行ファイルは、パッケージ定義によると「マイグレーション」フォルダ内のサブフォルダに配置する必要があります。

プラグイン内の最新の移行をテストするためのプラグイン固有の変更履歴を作成できます。この場合、プラグインにはデータベース接続が正しく定義されている必要があり、理想的にはプラグインテスト用に予約されたdbスキーマを指している必要があります。当然のことながら、プラグインのDBの設定は、アプリケーション自体のDEVスキーマを指すことができ

我々はコアプラグインの「移行」フォルダ内に以下のファイルがあります:私たちは中にマイグレーションをテストする必要があり

changelog.groovy 
core/000-initial.groovy 
core/001-drop-constr-XXX.groovy 

アプリケーション環境(ただし、リリース段階で最新)、我々は、アプリケーションプロジェクトの「移行」フォルダにテストした移行のすべてをコピーするので、我々はこのようなものでしょう:私たちは、アプリケーションのマスターで移行を含め

core/000-initial.groovy 
core/001-drop-constr-XXX.groovy 
accounting/000-initial.groovy 
accounting/001-add-col-yyy-to-posting-table.groovy 

をチャンこれELOG(プラグインの依存関係を満たす)のようになります。

databaseChangeLog = {  
    include file: 'core/000-initial.groovy' 
    include file: 'accounting/000-initial.groovy' 
    include file: 'core/001-drop-constr-XXX.groovy' 
    include file: 'accounting/001-add-col-yyy-to-posting-table.groovy' 
} 

我々はアプリケーションの開発データベースのスキーマに移行をテストすることができ、ファイルをコピーした後。

コピーした移行を変更する必要がある場合は、プラグインの移行フォルダ内の元の移行ファイルに変更が反映されるようにする必要があります(他のアプリケーションでこれらのプラグインの移行が使用される可能性があるため)。

0

私は同じことを調査しています(この記事を見つけました)。

  1. データベース移行プラグインのブランチを作成しての最初の検索し、それを変更する:最後に、私は(私自身の考えよりも良いかもしれない)あなたを含まない、を考え出すことができる唯一のいくつかのオプションがあります変更ログのフォルダ構造、次に他のリソース
  2. 変更履歴をアプリの変更履歴パス(通常は移行)にコピーするプラグイン(プロジェクト/アプリ内)のインストール時にトリガーされるスクリプトを作成します。
  3. Groovyロジックをchangelogに追加すると、そのルックアップが含まれ、プラグインフォルダが返されます。
+0

ありませんリンクが装着されています。 –

1

私のソリューションは、異なる環境間での共通スクリプトのdevtestlivecommonのように異なるフォルダを定義することです。

ディレクトリ構造は次のようになります。

P.S.その後

/** 
* Database Migration Config 
*/ 
//Enable database migration to run automatically 
grails.plugin.databasemigration.updateOnStart = true 

environments { 
    development { 
      grails.plugin.databasemigration.updateOnStartFileNames = ['changelog_dev.groovy'] 
    } 
    test { 
      grails.plugin.databasemigration.updateOnStartFileNames = ['changelog_test.groovy'] 
    } 
    production { 
     grails.plugin.databasemigration.updateOnStartFileNames = ['changelog_live.groovy'] 
    } 
} 

、changelog_ environmentは、任意のフォルダを参照することができます:changelog_ENVIRONMENT

Directory Structure

migrationsの下で私のConfig.groovyがどのように見えるです。 注:javaスタイルのパッケージ名(com.example.class)が私のために働いていなかったので、パッケージ名は1語だけ使用されています。

サンプル:
migrations/common/001-common-script.groovy

package common 

databaseChangeLog = { 

    changeSet(author: "author", id: "some-id") { 

    } 
} 

migrations/dev/001-dev-script.groovy

package dev 

databaseChangeLog = { 

    changeSet(author: "author", id: "some-other-id") { 

    } 
} 

migrations/changelog_dev.groovy

import dev.* 
import common.* 

databaseChangeLog = { 

    include file: 'common/001-common-script.groovy' 
    include file: 'dev/001-dev-script.groovy' 
} 
関連する問題