1. 序章

このチュートリアルでは、 Flyway の主要な概念と、このフレームワークを使用してアプリケーションのデータベーススキーマを確実かつ簡単に継続的に再構築する方法について説明します。 さらに、MavenFlywayプラグインを使用してインメモリH2データベースを管理する例を示します。

Flywayは、移行を使用してデータベースをあるバージョンから次のバージョンに更新します。データベース固有の構文を使用するSQL、または高度なデータベース変換用のJavaのいずれかで移行を記述できます。

移行は、バージョン管理または繰り返し可能のいずれかです。 前者には独自のバージョンがあり、1回だけ適用されます。 後者にはバージョンがありません。 代わりに、チェックサムが変更されるたびに（再）適用されます。

1回の移行実行では、保留中のバージョン管理された移行が実行された後、繰り返し可能な移行が常に最後に適用されます。 繰り返し可能な移行は、説明の順に適用されます。 単一の移行の場合、すべてのステートメントは単一のデータベーストランザクション内で実行されます。

このチュートリアルでは、主にMavenプラグインを使用してデータベースの移行を実行する方法に焦点を当てます。

2. FlywayMavenプラグイン

Flyway Mavenプラグインをインストールするには、次のプラグイン定義を pom.xmlに追加しましょう：

<plugin>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-maven-plugin</artifactId>
    <version>8.0.0</version> 
</plugin>

プラグインの最新バージョンは、 MavenCentralで入手できます。

このMavenプラグインは4つの異なる方法で構成できます。 次のセクションでは、これらの各オプションについて説明します。

構成可能なすべてのプロパティのリストを取得するには、ドキュメントを参照してください。

2.1. プラグインの構成

私たちはできるプラグインを直接設定します鬼ごっこ私たちのプラグイン定義で pom.xml：

<plugin>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-maven-plugin</artifactId>
    <version>8.0.0</version>
    <configuration>
        <user>databaseUser</user>
        <password>databasePassword</password>
        <schemas>
            <schema>schemaName</schema>
        </schemas>
        ...
    </configuration>
</plugin>

2.2. Mavenプロパティ

pomで構成可能なプロパティをMavenプロパティとして指定することにより、プラグインを構成することもできます。

<project>
    ...
    <properties>
        <flyway.user>databaseUser</flyway.user>
        <flyway.password>databasePassword</flyway.password>
        <flyway.schemas>schemaName</flyway.schemas>
        ...
    </properties>
    ...
</project>

2.3. 外部設定ファイル

別のオプションは、別の.confファイルでプラグイン構成を提供することです：

flyway.user=databaseUser
flyway.password=databasePassword
flyway.schemas=schemaName
...

デフォルトの構成ファイル名はflyway.confで、デフォルトでは次の場所から構成ファイルをロードします：

  • installDir / conf / flyway.conf
  • userhome / flyway.conf
  • workingDir / flyway.conf

エンコーディングは、 flyway.encoding プロパティで指定されます（ UTF-8 がデフォルトです）。

構成ファイルとして他の名前（ customConfig.conf など）を使用する場合は、Mavenコマンドを呼び出すときにこれを明示的に指定する必要があります。

$ mvn -Dflyway.configFiles=customConfig.conf

2.4. システムプロパティ

最後に、コマンドラインでMavenを呼び出すときに、すべての構成プロパティをシステムプロパティとして指定することもできます：

$ mvn -Dflyway.user=databaseUser -Dflyway.password=databasePassword 
  -Dflyway.schemas=schemaName

構成が複数の方法で指定されている場合の優先順位は次のとおりです。

  1. システムプロパティ
  2. 外部設定ファイル
  3. Mavenのプロパティ
  4. プラグイン構成

3. 移行の例

このセクションでは、 Mavenプラグインを使用してデータベーススキーマをインメモリH2データベースに移行するために必要な手順を説明します。外部ファイルを使用して、Flywayを構成します。

3.1. POMを更新する

まず、依存関係としてH2を追加しましょう。

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.196</version>
</dependency>

ここでも、 MavenCentralで利用可能な最新バージョンのドライバーを確認できます。 前に説明したように、Flywayプラグインも追加します。

3.2. 外部ファイルを使用してFlywayを構成する

次に、 $PROJECT_ROOTにmyFlywayConfig.confを次の内容で作成します。

flyway.user=databaseUser
flyway.password=databasePassword
flyway.schemas=app-db
flyway.url=jdbc:h2:mem:DATABASE
flyway.locations=filesystem:db/migration

上記の構成は、移行スクリプトが db /migrationディレクトリにあることを指定しています。 databaseUserおよびdatabasePasswordを使用してメモリ内のH2インスタンスに接続します。

アプリケーションデータベーススキーマはapp-dbです。

もちろん、 flyway.user、flyway.password、、 flyway.url は、それぞれ独自のデータベースユーザー名、データベースパスワード、データベースURLに置き換えられます。

3.3. 最初の移行を定義する

Flywayは、移行スクリプトの次の命名規則に準拠しています。

__ .sql

どこ：

  • –デフォルトのプレフィックスは V 、上記の構成ファイルで変更できます。 flyway.sqlMigrationPrefix 財産。
  • –移行バージョン番号。 メジャーバージョンとマイナーバージョンは、アンダースコアで区切ることができます。 移行バージョンは常に1で始まる必要があります。
  • –移行のテキストによる説明。 二重下線は、説明とバージョン番号を区切ります。

例： V1_1_0__my_first_migration.sql

それでは、従業員テーブルを作成するためのSQL命令を含む V1_0__create_employee_schema.sql という名前の移行スクリプトを使用して、 $PROJECT_ROOTにディレクトリdb/migrationを作成しましょう。

CREATE TABLE IF NOT EXISTS `employee` (

    `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `name` varchar(20),
    `email` varchar(50),
    `date_of_birth` timestamp

)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

3.4. 移行を実行する

次に、 $ PROJECT_ROOT から次のMavenコマンドを呼び出して、データベースの移行を実行します。

$ mvn clean flyway:migrate -Dflyway.configFiles=myFlywayConfig.conf

これにより、最初の移行が成功するはずです。

データベーススキーマは次のようになります。

employee:
+----+------+-------+---------------+
| id | name | email | date_of_birth |
+----+------+-------+---------------+

定義と実行の手順を繰り返して、さらに移行を行うことができます。

3.5. 2番目の移行を定義して実行する

次の2つのクエリを含むV2_0_create_department_schema.sqlという名前の2番目の移行ファイルを作成して、2番目の移行がどのようになるかを見てみましょう。

CREATE TABLE IF NOT EXISTS `department` (

`id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
`name` varchar(20)

)ENGINE=InnoDB DEFAULT CHARSET=UTF8; 

ALTER TABLE `employee` ADD `dept_id` int AFTER `email`;

次に、最初に行ったのと同様の移行を実行します。

これで、データベーススキーマが変更され、従業員に新しい列と新しいテーブルが追加されました： 

employee:
+----+------+-------+---------+---------------+
| id | name | email | dept_id | date_of_birth |
+----+------+-------+---------+---------------+
department:
+----+------+
| id | name |
+----+------+

最後に、次のMavenコマンドを呼び出すことで、両方の移行が実際に成功したことを確認できます。

$ mvn flyway:info -Dflyway.configFiles=myFlywayConfig.conf

4. IntelliJIDEAでバージョン管理された移行を生成する

移行を手動で作成するには、多くの時間がかかります。 代わりに、JPAエンティティに基づいてそれらを生成できます。JPAバディと呼ばれるIntelliJIDEAのプラグインを使用してこれを実現できます。

差分バージョン移行を生成するには、プラグインをインストールし、JPA構造パネルからアクションを呼び出すだけです。

比較するソース（データベースまたはJPAエンティティ）をターゲット（データベースまたはデータモデルのスナップショット）と選択するだけです。 次に、アニメーションに示すように、JPAバディが移行を生成します。

JPAバディのもう1つの利点は、Javaとデータベースタイプ間のマッピングを定義できることです。 また、HibernateカスタムタイプおよびJPAコンバーターでも正しく機能します。

5. SpringBootでFlywayを無効にする

特定の状況下でFlywayの移行を無効にする必要がある場合があります。

たとえば、テスト中にエンティティに基づいてデータベーススキーマを生成するのが一般的な方法です。 このような状況では、testプロファイルでFlywayを無効にすることができます。

Spring Bootでがいかに簡単か見てみましょう。

5.1. スプリングブート1.x

application-test.propertiesファイルでflyway.enabledプロパティを設定するだけです。

flyway.enabled=false

5.2. Spring Boot 2.x

Spring Bootの最新バージョンでは、このプロパティはspring.flyway.enabled：に変更されました。

spring.flyway.enabled=false

5.3. 空のFlywayMigrationStrategy

起動時に自動Flyway移行を無効にするだけで、手動で移行をトリガーできる場合は、上記のプロパティを使用することはお勧めできません。

これは、このような状況では、Spring Bootが Flywaybeanを自動構成しなくなるためです。 したがって、自分で提供する必要があり、あまり便利ではありません。

したがって、これが私たちのユースケースである場合、Flywayを有効のままにして、空のFlywayMigrationStrategyを実装できます。

@Configuration
public class EmptyMigrationStrategyConfig {

    @Bean
    public FlywayMigrationStrategy flywayMigrationStrategy() {
        return flyway -> {
            // do nothing  
        };
    }
}

これにより、アプリケーションの起動時にFlywayの移行が効果的に無効になります。

ただし、手動で移行をトリガーすることはできます。

@RunWith(SpringRunner.class)
@SpringBootTest
public class ManualFlywayMigrationIntegrationTest {

    @Autowired
    private Flyway flyway;

    @Test
    public void skipAutomaticAndTriggerManualFlywayMigration() {
        flyway.migrate();
    }
}

6. Flywayの仕組み

すでに適用した移行とその時期を追跡するために、スキーマに特別な簿記テーブルが追加されます。 このメタデータテーブルは、移行チェックサム、および移行が成功したかどうかも追跡します。

フレームワークは、進化するデータベーススキーマに対応するために次の手順を実行します。

  1. データベーススキーマをチェックして、メタデータテーブル（デフォルトでは SCHEMA_VERSION ）を見つけます。 メタデータテーブルが存在しない場合は、作成されます。
  2. アプリケーションのクラスパスをスキャンして、利用可能な移行を探します。
  3. 移行をメタデータテーブルと比較します。 バージョン番号が現在としてマークされているバージョン以下の場合、それは無視されます。
  4. 残りの移行を保留中の移行としてマークします。 これらはバージョン番号に基づいてソートされ、順番に実行されます。
  5. 移行が適用されるたびに、メタデータテーブルはそれに応じて更新されます。

7. コマンド

Flywayは、データベースの移行を管理するために次の基本的なコマンドをサポートしています。

  • 情報：データベーススキーマの現在のステータス/バージョンを出力します。 保留中の移行、適用された移行、適用された移行のステータス、およびそれらがいつ適用されたかを出力します。
  • 移行：データベーススキーマを現在のバージョンに移行します。 クラスパスをスキャンして利用可能な移行を探し、保留中の移行を適用します。
  • ベースライン： baselineVersion を含むすべての移行を除いて、既存のデータベースをベースライン化します。 ベースラインは、既存のデータベースのFlywayから始めるのに役立ちます。 その後、新しい移行を通常どおりに適用できます。
  • 検証：現在のデータベーススキーマを利用可能な移行に対して検証します。
  • 修理：メタデータテーブルを修理します。
  • Clean：構成されたスキーマ内のすべてのオブジェクトをドロップします。 もちろん、本番データベースでcleanを使用しないでください。

8. 結論

この記事では、Flywayがどのように機能し、このフレームワークを使用してアプリケーションデータベースを確実に再構築する方法を学びました。

この記事に付随するコードは、GitHubでから入手できます。