====== <Contexts> タグ ======

"Contexts" は、LiquiBase のタグであり、変更セットに追加して、特定の移行が実行されるときにあわせて実行されるかどうかを制御するものです。どんな文字列でもコンテキスト名に指定することができ、文字列の大文字と小文字は区別されません。

どんなやり方でも migrator を実行するとき、それらをコンテキストの集まりに渡すことができます。承認されたコンテキストを持つ変更セットだけが実行されます。

変更セットにコンテキストを追加しない場合、migrator にどんなコンテキストを渡したとしても常に実行されます。

migrator を実行するときにコンテキストを特定しない場合、すべてのコンテキストが実行されます。

下記は、context 属性を利用した変更セットの例です:
<code>
   <changeSet id="2" author="bob" context="test">
        <insert tableName="news">
            <column name="id" value="1"/>
            <column name="title" value="Liquibase 0.8 Released"/>
        </insert>
        <insert tableName="news">
            <column name="id" value="2"/>
            <column name="title" value="Liquibase 0.9 Released"/>
        </insert>
    </changeSet>
</code>

===== テストデータのためにコンテキストを使う =====

テストデータを LiquiBase を用いて管理している場合、もっともよいやり方はほかの変更セットとともにそれをインラインでインクルードし、ただし "test" コンテキストとしてマークすることです。このやり方ですと、インサートされたテストデータをテストしたいときには、migrator を "test" コンテキストで実行すればよいのです。本番環境に移行することになったら、"test" コンテキストをインクルードしてはいけません、そうすればテストデータはインクルードされないのです。複数のテスト環境やテストデータセットを持っている場合、単純に "min-test" , "integration-text" などのように異なったコンテキストでタグ付けします。

テストデータを制御するためにコンテキストを利用するのは、別々の変更ログツリーを利用するよりよいことです。なぜなら、後で発生するリファクタリングや変更は、本番環境のデータだけでなく、存在するテストデータに対しても適用されるからです。データベースがセットアップされた後に作成され、単純に追加されたテストデータの集まりがあるようにしてしまうと、つねに手動でテストデータスクリプトを、現行のデータベーススキーマにあうように変更し続けることになってしまうでしょう。


===== 変更セットに複数のコンテキストを利用する =====

一つの変更セットに、複数のコンテキストでタグ付けをしたい場合は、それらをカンマ(,) で分割します。ひとつの変更セットに複数のコンテキストを指定した場合、migrator に渡されたコンテキストのうち一つだけが適合していればいいのです。


=====  複数種類のデータベースの変更ログにコンテキストを利用する =====

データベースごとに対応する変更セットを制御するためにコンテキストを利用することもできますが、よりよいやり方はビルトインされた changeSet タグの "dbms" タグを利用することです。