この記事では、データベースの移行を有効にするために、スプリングブート用のフライウェイの使用を紹介します。それはあなたと共有されます。詳細は次のとおりです。
まず、最初にフライウェイの仕組みを理解させてください。
最も簡単な解決策は、フライウェイを空のデータベースに向けることです。
メタデータテーブルを見つけようとします。データベースが空の場合、Flywayはそれを見つけませんが、作成します。これで、schema_versionという名前の1つの空のテーブルを備えたデータベースがあります。
このテーブルは、データベースの状態を追跡するために使用されます。その後、FlywayはアプリケーションのファイルシステムまたはClassPathのスキャンを開始し、移行を開始します。それらはSQLまたはJavaで書くことができます。
次に、移行をバージョン番号で並べ替えて、次の順に適用します。
各移行が適用されると、それに応じてメタデータテーブルが更新されます。
schema_version
メタデータと初期状態が整っていると、新しいバージョンへの移行について話すことができます。
Flywayは、アプリケーションのファイルシステムまたはClassPathを再度スキャンして移行します。メタデータテーブルに対する移行を確認してください。バージョン番号が現在のバージョンとしてマークされたバージョン番号以下の場合、それらは無視されます。
残りの移行は移行が保留中です：利用可能ですが、適用されません。
次に、バージョン番号ごとにソートし、順番に実行します。
このメタデータテーブルが更新されるので、
schema_version
それでおしまい！データベースが構造（DDL）であろうと参照データ（DML）であろうと、データベースを開発する必要があるときはいつでも、現在のバージョンよりも高いバージョン番号で新しい移行を作成するだけです。次回のフライウェイが開始されると、それに応じてデータベースを発見してアップグレードします。
2。スプリングブートでのフライウェイの使用
1つの方法は、hibernate.hbm2ddl.autoプロパティを設定して、spring bootのspring.jpa.hibernate.ddl-autoプロパティを介して作成、作成、または更新することです。たとえば、hibernate.hbm2ddl.autoを作成するには、application.ymlに次のコンテンツを追加できます。
春：JPA：Hibernate：ddl-auto：create-drop
ただし、これは生産環境に理想的ではありません。アプリケーションがデータベースを再起動するたびに、スキーマが空になり、ゼロから再構築されるためです。更新するように設定できますが、それでも、生産環境に使用することはお勧めしません。
別の方法があります。 Schema.sqlでスキーマを定義できます。最初の実行では、これを行うのに問題はありませんが、アプリケーションが開始されるたびに、データテーブルが既に存在するため、この初期化スクリプトは失敗します。これには、初期化スクリプトを作成し、行われた作業を繰り返さない場合は、特別な注意が必要です。
より良いオプションは、データベース移行ライブラリを使用することです。使用されており、同じスクリプトを複数回使用していない一連のデータベーススクリプトとレコードを使用します。アプリケーションの各展開パッケージにはこれらのスクリプトが含まれており、データベースはアプリケーションと一致する可能性があります。 Spring Bootは、2つの一般的なデータベース移行ライブラリの自動構成サポートを提供します。
Spring Bootでこれらのライブラリのいずれかを使用する場合は、プロジェクトに対応する依存関係を追加してスクリプトを作成するだけです。フライウェイから始めましょう。
1.フライウェイを使用して、データベースの移行プロセスを定義します
Flywayは、SQLを使用して移行スクリプトを定義する非常にシンプルなオープンソースデータベース移行ライブラリです。アイデアは、各スクリプトにバージョン番号があり、Flywayがこれらのスクリプトを順番に実行して、データベースを目的の状態にすることです。また、実行されたスクリプトステータスを記録し、繰り返されません。読み取りリストアプリケーションでは、データテーブルとデータのない空のデータベースから始めます。したがって、このスクリプトは、外部のキーの制約と初期化データを含む、最初に読者と予約テーブルを作成する必要があります。コードの8-2のリストは、空のデータベースから利用可能な状態までのフライウェイスクリプトです。
フライウェイデータベース初期スクリプト
テーブルリーダーを作成します（IDシリアルプライマリキー、ユーザー名Varchar（25）一意ではないnull、パスワードvarchar（25）not null、fullname varchar（50）not null）;テーブルブック（IDシリアルプライマリキー、著者varchar（50）not null、description varchar（1000）not null、isbn varchar（10）null、title varchar（250）null not null、reader_username varchar（25）null、fortion key（reader_username）参考文献reader（username））;シーケンスhibernate_sequence; inserting into reader（username、password、fullname）values（ 'craig'、 'password'、 'craig Walls'）を作成します。
ご覧のとおり、フライウェイスクリプトはSQLです。それを機能させるのは、ClassPathの場所とファイル名です。フライウェイスクリプトはすべて、図8-1に示すように、バージョン番号を含む命名仕様に従います。
すべてのフライウェイスクリプトには、大文字Vで始まる名前があり、その後にスクリプトのバージョン番号が続きます。 2つのアンダースコアとスクリプトの説明が続きます。これは移行プロセス全体の最初のスクリプトであるため、そのバージョンは1です。説明は非常に柔軟であり、主にスクリプトの目的を理解するために使用されます。その後、データベースに新しいテーブルを追加するか、既存のデータテーブルに新しいフィールドを追加する必要があります。バージョン番号2で別のスクリプトを作成できます。フライウェイスクリプトは、アプリケーションクラスパスルートパスに比べて /db /移行パスの下に配置する必要があります。したがって、プロジェクトでは、スクリプトをSRC/Main/Resources/DB/Migrationに配置する必要があります。また、hibernateがデータテーブルを作成しないように、spring.jpa.hibernate.ddl-autoをなしに設定する必要があります。これは、application.ymlの次のコンテンツに関連しています。
春：JPA：Hibernate：ddl-auto：なし
残っているのは、プロジェクトの依存としてフライウェイを追加することだけです。 Gradleでは、この依存関係は次のようになります。
コンパイル（ "org.flywaydb：flyway-core"）
Mavenプロジェクトでは、次のように見えます。
<Dependency> groupId> org.flywayfb </groupid> <artifactid>フライウェイコア</artifactid> </dependency>
アプリケーションが展開されて実行された後、Spring Bootはクラスパスのフライウェイを検出し、必要な豆を自動的に構成します。 Flywayでは、スクリプトを /db /migrationで順番に表示し、実行されていない場合はこれらのスクリプトを実行します。各スクリプトが実行されたら、schema_versionテーブルにレコードを書きます。次にアプリケーションが開始されると、FlywayはまずSchema_versionのレコードを見て、それらのスクリプトをスキップします。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。