データベースのバージョニング

データベースファースト

このアプローチでは、データベースがデータモデルクラス（POJO や JPA エンティティ）よりも優先されます。これらのクラスは、コード生成を通じてデータベースのスキーマから生成されます（「データベースリバースエンジニアリング」とも呼ばれます）。生成されたクラスはいつでも再生成される可能性があるため、変更は避けてください。ソースコードに加えた変更は失われてしまいます。 ただし、このアプローチでは マイグレーションスクリプト生成の必要性を排除できません 。既存のシステムを最新バージョンにアップグレードするために必要となります。

ソースコードファースト

こちらは逆のアプローチで、データモデルクラスが唯一の信頼できるソースとなります。 そのため、データモデルの変更によりデータベースが更新されます。 データベースを更新するには、マイグレーションスクリプトで古いデータベースと現在のデータモデルクラスとの差分を表現する必要があります。これには、Flyway SQL マイグレーションや Liquibase 変更ログなど、任意のフォーマットを使用できます。

IntelliJ IDEA は、開発者がこれら 2 つのシナリオのそれぞれを進めるのに役立つ便利なツールを提供します。 このガイドでは、IntelliJ IDEA が差分更新スクリプトの生成にかかる時間を大幅に節約する方法を説明します。

ライブラリサポート

IntelliJ IDEA は、JPA とともに Java アプリケーションでよく使用される 2 つの一般的なソリューションをサポートしています。

• Liquibase

• Flyway

一般的な差分スクリプトの生成 Flow

このセクションでは、移行スクリプト生成の基本原則について説明します。 Liquibase および Flyway で移行スクリプトを生成する方法の詳細については、 Liquibase および Flyway を参照してください。

差分移行スクリプトを生成するには、 データベース でデータベース接続を右クリックし、 Liquibase 変更ログを作成する または Flyway バージョン移行の作成 を選択します。 ビルドファイルに JPA および Liquibase または Flyway 依存関係が追加されている場合、アクションは使用できます。

開いたダイアログで、ソース (データモデルの望ましい状態) とターゲット (データモデルの古い状態) を選択します。

結果の移行スクリプト = 現在の状態 (ソース) – 以前の状態 (ターゲット)。

IntelliJ IDEA は、ターゲットデータベースをソースの状態にアップグレードするための移行スクリプトを生成します。

次のソースオプションから選択できます。

• DB — 最新のデータベースがあり、別の DB を同じ状態に更新するための移行スクリプトを生成したい場合に使用する必要があります。

• モデル — エンティティ関係モデル (JPA エンティティ) の現在の状態と古い (ターゲット) 状態の違いを表す移行スクリプトを生成するために使用します。

ターゲットは次のように設定できます。

• DB — ターゲット DB のスキーマが古いバージョンです。

• スナップショット - 必要な状態がデータモデルのスナップショットに保存されている場合は、このオプションを使用します。 これは JPA Buddy でも生成できます。

「OK」をクリックして次に進みます。 JPA Buddy はソースとターゲットの違いを分析し、結果の移行スクリプトを微調整できるようにプレビューダイアログを表示します。 「保存」をクリックして、新しいスクリプトをプロジェクトに追加するか、既存のスクリプトを追加します。

差分移行スクリプト生成オプション

データベースの使用

ソースデータベースがデータモデルとすでに同期されている場合、データベースを別のデータベース / スナップショットと比較することは理にかなっています。 JPA エンティティに従ってデータベースを維持するには、次の 2 つの一般的なアプローチがあります。

• スキーマ自動ジェネレーターの使用 (Hibernate および EclipseLink は独自の実装を提供します)。 Hibernate のドキュメントでも、プロトタイピングやテストの目的を超えてこの方法を使用しないように警告していることに注意してください。

• JPA エンティティの変更をデータベーススキーマに手動で適用します。 このアプローチは、特にデータモデルが頻繁に変更される開発初期段階では、手間がかかりすぎるように見えるかもしれません。

データモデルの使用

アプリケーションは、JPA エンティティを使用して、JPA 原則に従って、エンティティ、関連付け、インデックス、その他の関連要素を含むデータモデルを表します。 つまり、データベーススキーマに関する十分な情報がすでに含まれています。 ソースコードが唯一の真実の点であり、最新の (ソース) スキーマを表します。 このため、差分変更ログを生成するには、データモデルをデータベース / スナップショットと比較することが望ましいのです。

IntelliJ IDEA はすべての JPA オブジェクトをスキャンし、ターゲットデータベースまたはスナップショットと比較して、差分移行スクリプトを生成します。

データモデルが現在のスキーマ状態のソースとして機能する場合、永続性ユニットが選択されます。

ドキュメントに従って (英語): 永続化ユニットは、アプリケーション内の EntityManager インスタンスによって管理されるすべてのエンティティクラスのセットを定義します。 このエンティティクラスのセットは、単一のデータストア内に含まれるデータを表します。

つまり、アプリケーションが複数のデータストアを使用する場合、対応する永続性ユニットを指定して、それぞれに対して個別に移行スクリプトを生成する必要があります。

データモデルのスナップショットの使用

IntelliJ IDEA では、データモデルスナップショットを比較のターゲットとして使用できます。 変更を以前のアプリケーションバージョンにマージする場合など、モデルの特定の状態のデータベースを取得することが不可能または困難な場合があります。 リリースごとにデータベースダンプを保持するのは不可能な場合があります。 IntelliJ IDEA を使用すると、必要なバージョンのアプリケーションをチェックアウトし、JPA エンティティに基づいて JSON スナップショットを生成できるため、差分移行スクリプトを作成するときにデータベースが不要になります。

データモデルスナップショットの生成

1. 永続化ツールウィンドウを開きます。

2. 要素を右クリックし、 新規 | データモデルのスナップショット を選択します。

これにより、古い時点でのデータモデルの状態をキャプチャーできるため、その時点から現在までに発生したすべての変更を記述した差分移行スクリプトを作成できます。

例: フィーチャーブランチで作業しており、モデルを変更しました。 マージする前に、このブランチのみの変更を説明する diff 変更ログを作成する必要があります。

設定によっては、メインのブランチと常に同期している DB がない場合があります。 リリースブランチなど、メインのブランチ以外のアプリケーションの状態に変更をマージする必要がある場合、状況はさらに複雑になります。 リリースごとにデータベースダンプを維持するのは現実的ではない可能性があります。 IntelliJ IDEA は、よりシンプルな代替手段を提供します。

1. ターゲットブランチをチェックアウトします (たとえば、メインまたはリリース)

2. ブランチでモデルのスナップショットを作成します

3. 機能をチェックアウトブランチ

4. モデルと手順 2 で作成したスナップショットを比較して、差分移行スクリプトを生成します。

4 つの簡単な手順で、現在のブランチとターゲットブランチの間の変更を記述した移行スクリプトを取得できます。

プレビューウィンドウ

Liquibase のプレビューウィンドウは次のようになります (Flyway のプレビューウィンドウは少し異なります)。

一部の種類の変更には、プレビューウィンドウにカスタムフィールドがあります。 例: 非 null 制約の追加、 DB 内のすべての既存の NULL 値を指定した値に置き換えることができます。

各変更の型は、その危険度に応じて色分けされています：安全は緑、注意は黄、危険は赤です。 安全な操作は、いかなる方法でもデータ損失を引き起こさないものです。たとえば、カラムの追加は既存のデータに影響を与えません。 注意が必要な操作は、一般的に安全ですが注意が求められます。たとえば、NOT NULL 制約を追加する場合、そのカラムに null 値があると失敗することがあります。 危険な操作はデータ損失を引き起こす可能性があります。例えば、カラムの削除やデータ型の変更などです。

危険レベルは、 ツール | データベースのバージョニング | 差分変更 の IDE 設定でカスタマイズできます。

各変更タイプの場所をプライマリまたはセカンダリの場所に構成することも、完全に無視することもできます。 デフォルトでは、新しく生成された移行スクリプトは無視された変更を除外しますが、それらの変更はプレビュー中に 無視 セクションに表示されるため、手動で追加し直すことができます。 Liquibase の場合、各変更タイプに使用するコンテキストとラベルを設定することもできます。

ステートメントのマージ

基本的に、テーブル名、列名などのスキーマ要素の名前を変更すると、次の 2 つのステートメントが生成されます。

• 既存の値を削除する

• 新しいものを追加

しかし、JPA Buddy は、このようなステートメントを単一の名前変更ステートメントまたは変更ステートメントに置き換えることができます。 例: 列 / テーブル / シーケンスの名前を変更したり、列の種類を変更したりすると、プレビューウィンドウに 2 つのステートメントが表示されます。 ただし、関連するステートメントのいずれかを選択すると、結合できます。

マージ後は、drop ステートメントは無関係になる可能性があります。 移行スクリプトから削除する変更を選択できます。 例: ID 列の名前を変更した後 (古い値を削除して新しい値を追加するのではなく)、それに新しい主キーを追加する必要はありません。

エンティティによる DDL

IntelliJ IDEA を使用すると、エンティティを DDL 文に変換できます。 以下の文を生成できます。

• エディターから直接 単一のエンティティの初期化スクリプトを取得します。

• 複数のエンティティの初期化スクリプト: モデル全体または選択したエンティティに基づいてデータベーススキーマを作成します。

• 差分 DDL: JPA エンティティに従って、既存のデータベースを有効な状態に更新します。

この機能は、 hbm2ddl または ddl-auto プロパティによって有効化される自動スクリプト生成の使用を避けたい場合に便利です。 この機能を使用することで、実行前に DDL を完全に制御し、Java から DB への適切な型マッピングを設定したり、属性コンバーターと Hibernate 型を使用してフィールドをマッピングしたり、ドロップステートメントを生成したり、その他多くのことが可能になります。

SQL ビジュアルデザイナー

場合によっては、特に新しいデータベースを迅速にセットアップする必要がある場合に、JPA データモデル用の SQL スクリプトがあると便利です。 JPA Buddy は、JPA パレットまたはエディターツールバーを介して幅広い SQL ステートメントを生成できます。 各ステートメントには、ステートメントを構成できる対応するウィンドウがあります。

Hibernate 6 サポート

Hibernate 6 より前は、非標準 SQL 型を Java 型にマッピングするために、Hibernate 型ライブラリまたは @Type/@Converter アノテーションが一般的に使用されていました。 Hibernate 6 では、マッピング用の新しいアノテーションが利用可能になり、多数の Hibernate 型と JPA コンバーターが不要になりました。 現在、IntelliJ IDEA は以下の新しいマッピングアノテーションをサポートしています。

• @JdbcType、 @JdbcTypeCode、 @JdbcTypeRegistration

• @Type、 @JavaType、 @JavaTypeRegistration

• @TimeZoneStorage & @TimeZoneColumn

Hibernate エンバースのサポート

Hibernate エンバース(英語)は、データベース内のエンティティ監査を容易にするモジュールです。 IntelliJ IDEA は、Hibernate Envers が正しく機能するために必要なすべてのテーブルを生成できます。 これには、 @Audited アノテーションが付与されたエンティティの監査テーブルと、 @RevisionEntity アノテーションが付与されたエンティティのリビジョンテーブルが含まれます。

JPA Buddy プラグインをインストールして有効化すると、リビジョンエンティティも生成できます。 実際にどのように動作するか、ぜひ参照してください。

監査対象エンティティの接尾辞や接頭辞など、Hibernate Envers の動作に関するさまざまな側面を設定できます。 Liquibase の変更ログや Flyway の移行スクリプトを生成する際には、これらの設定をプロパティファイルから使用するか、 IntelliJ IDEA の専用設定ページで設定することができます。

設定

カスタム型マッピング

カスタム Java タイプを SQL/Liquibase タイプに自動的にマップする一般的な方法はありません。 そのため、これらの属性のターゲットタイプを手動で定義する必要があります。 プロジェクトにこのような属性が存在する場合、Liquibase または Flyway スクリプト生成アクションが呼び出された後、JPA Buddy は次のウィンドウを表示します。

保存されたマッピング構成は、 ツール | JPA Buddy | データベースのバージョニング | 型マッピング からいつでも変更できます。

また、アプリケーションがさまざまなベンダーのデータベースと連携する場合にも役立つ場合があります。 この場合、スキーマのデータ型はそれぞれわずかに異なる可能性があります。

アプリケーションが PostgreSQL と MS SQL の両方をサポートする必要があるとします。 そして、Unicode 文字を文字列に保存したいとします。 PostgreSQL は VARCHAR の Unicode 文字をサポートしますが、MS SQL にはそれ用の別の NVARCHAR データ型があります。

各 DBMS の型マッピングを指定できます。 また、JPA コンバーターと Hibernate 型のマッピングを設定することもできます。

コンバーター

型マッピングを簡素化するために、IntelliJ IDEA は DB に依存しない SQL 型を導入し、DB 固有の型に変換します。 例: 「varchar」は Oracle DB では「varchar2」に変換され、PostgreSQL では「varchar」のままになります。

DB に依存しない各タイプには、一連のエイリアス (たとえば、「java.sql.Types.VARCHAR」または「character varying」) があり、ほとんどの場合は互換性があります。 不明なタイプは、変換されずにそのまま使用されます。 表のエイリアスの完全なリストを確認してください。

名前	エイリアス	Liquibase クラス
bigint	java.sql.Types.BIGINT、 java.math.BigInteger、 java.lang.Long、 integer8、 bigserial、 serial8、 int8	liquibase.datatype.core.BigIntType
blob	longblob、 longvarbinary、 java.sql.Types.BLOB、 java.sql.Types.LONGBLOB、 java.sql.Types.LONGVARBINARY、 java.sql.Types.VARBINARY、 java.sql.Types.BINARY、 varbinary、 2 進数、 image、 tinyblob、 mediumblob	liquibase.datatype.core.BlobType
boolean	java.sql.Types.BOOLEAN、 java.lang.Boolean、 bit、 bool	liquibase.datatype.core.BooleanType
char	java.sql.Types.CHAR、 bpchar	liquibase.datatype.core.CharType
clob	longvarchar、 テキスト、 longtext、 java.sql.Types.LONGVARCHAR、 java.sql.Types.CLOB、 nclob、 longnvarchar、 ntext、 java.sql.Types.LONGNVARCHAR、 java.sql.Types.NCLOB、 tinytext、 mediumtext	liquibase.datatype.core.ClobType
currency	money、 smallmoney	liquibase.datatype.core.CurrencyType
関数	liquibase.statement.DatabaseFunction	liquibase.datatype.core.DatabaseFunctionType
datetime	java.sql.Types.DATETIME、 java.util.Date、 smalldatetime、 datetime2	liquibase.datatype.core.LiquibaseDataType
date	java.sql.Types.DATE、 java.sql.Date	liquibase.datatype.core.DateType
10 進数	java.sql.Types.DECIMAL、 java.math.BigDecimal	liquibase.datatype.core.DecimalType
double	java.sql.Types.DOUBLE、 java.lang.Double	liquibase.datatype.core.DoubleType
float	java.sql.Types.FLOAT、 java.lang.Float、 real、 java.sql.Types.REAL	liquibase.datatype.core.FloatType
int	integer、 java.sql.Types.INTEGER、 java.lang.Integer、 serial、 int4、 serial4	liquibase.datatype.core.IntType
mediumint		liquibase.datatype.core.MediumIntType
nchar	java.sql.Types.NCHAR、 nchar2	liquibase.datatype.core.NCharType
個数	numeric、 java.sql.Types.NUMERIC	liquibase.datatype.core.NumberType
nvarchar	java.sql.Types.NVARCHAR、 nvarchar2、 national	liquibase.datatype.core.NVarcharType
smallint	java.sql.Types.SMALLINT、 int2	liquibase.datatype.core.SmallIntType
timestamp	java.sql.Types.TIMESTAMP、 java.sql.Types.TIMESTAMP_WITH_TIMEZONE、 java.sql.Timestamp、 timestamptz	liquibase.datatype.core.TimestampType
time	java.sql.Types.TIME、 java.sql.Time、 timetz	liquibase.datatype.core.TimeType
tinyint	java.sql.Types.TINYINT	liquibase.datatype.core.TinyIntType
uuid	uniqueidentifier、 java.util.UUID	liquibase.datatype.core.UnknownType
varchar	java.sql.Types.VARCHAR、 java.lang.String、 varchar2、 character varying	liquibase.datatype.core.VarcharType
xml	xmltype、 java.sql.Types.SQLXML	liquibase.datatype.core.XMLType

Hibernate エンバース

Hibernate Envers は 様々なカスタマイズオプション(英語)を提供します。 IDE 設定で設定を指定することも、 .properties ファイルから既存の設定を IntelliJ IDEA に自動的に読み取らせることもできます。

命名戦略

デフォルトでは、Spring Boot は SpringPhysicalNamingStrategy を使用して物理的な命名戦略を構成します。 この実装では、すべてのテーブル名がアンダースコアで区切られた小文字で生成されます。 例: TelephoneNumber エンティティは telephone_number テーブルにマップされます。 エンティティに @Table(name = "TelephoneNumber") でアノテーションを付ける場合でも、移行スクリプトでは同じ名前を使用する必要があります。 そのため、JPA Buddy はスクリプト生成中にすべての名前に物理的な命名戦略も適用します。

次の戦略がサポートされています。

• SpringPhysicalNamingStrategy – デフォルトのオプション

• PhysicalNamingStrategyStandardlmpl

• CamelCaseToUnderscoresNamingStrategy (Hibernate 6 以降のバージョンのプロジェクトのみ)

命名戦略の詳細については、 記事(英語)を参照してください。

カスタム命名戦略

場合によっては、プロジェクト内の命名戦略のデフォルトの動作が変更されることがあります。 JPA Buddy もそれをお手伝いします。 プロジェクト内で org.hibernate.boot.model.naming.PhysicalNamingStrategy (またはその後継の 1 つ) を実装するクラスが検出されると、対応するクラスを含む追加の「カスタム」セクションが命名戦略ドロップダウンメニューに表示されます。

ドロップダウンメニューからこのクラスを選択すると、IntelliJ IDEA は移行スクリプトを生成するときにこの戦略を使用します。 IntelliJ IDEA はクラスの変更を自動的に更新しないため、戦略コードを変更する場合は、 カスタム物理命名戦略クラスを再ロード をクリックするか、IntelliJ IDEA を再起動する必要があります。

最大識別子

RDBMS には独自の制限があります。 例: 12.1 バージョンより前の OracleDatabase(英語) のテーブル名は 30 バイトに制限されています。 バージョン管理スクリプトの問題を回避するために、テーブル名を制限できます。

また、次のように定義することもできます。

• 関連外部キー制約のインデックスを作成するかどうか。

• 主キー制約名。