一部のシナリオでは、特定のデータベースの再編成により、現在のプログラムと新しいデータベーススキーマの互換性が失われるかどうかを事前に把握しておくと便利なことがあります。
このような状況を初期段階で認識できるように、GeneXus は影響分析レポートに次の情報メッセージを追加しました:
nfo0003: The reorganization for this table makes the schema not backward compatible. (このテーブルの再編成により、スキーマの下位互換性が失われます)
したがって、データベースに変更を適用するか、または現在のプログラムとの互換性を維持するために別の方法で再編成を実行するかを選択できます。
以下に、起こりうるシナリオと、影響分析時に実行されるさまざまな制御について説明します。
データモデルに変更が行われた場合、GeneXus はデータベースを影響分析するだけでなく、その変更によって影響を受ける可能性のあるすべてのプログラムを再生成します。つまり、データベースのバージョン v1 からバージョン v2 への変更は、バイナリの変更 (v1 → v2) も意味します。
データモデルのこれらの変更は、以前のプログラムと互換性のある新しい物理モデルまたはスキーマを必ずしも生成するわけではありません。また、v1 と v2 のプログラムを相互に排他的な方法でデプロイすることは、必ずしも可能ではありません。つまり、v1 と v2 のプログラムが同時にデータベースに接続することを防ぐことはできません。
以下は、v2 のプログラムが v1 のプログラムと一定期間共存し、同じ v2 バージョンのデータベースにアクセスする必要があるシナリオです:
- 高可用性シナリオおよびロードバランシングを使用する複数のノード: 古いプログラムを実行しているノードもあれば、既に新しいプログラムの実行を開始しているノードもある場合です。
- A/B テストのシナリオ: 新しいプログラムを実行しているユーザーセグメントもあれば、古いプログラムを実行しているユーザーセグメントもある場合です。
- ミニサービスのアーキテクチャのシナリオ: さまざまなアプリケーション、Web アプリケーション、プロセス、サードパーティに公開されたサービス、同じデータベースへのアクセスがあり、これらのアプリケーションの一部のみを v2 にアップグレードし、それ以外は v1 で実行する必要がある場合です。
この時間は不確定であることに留意してください。数秒の場合もありますが、数日、数か月になる場合もあります。
これらのシナリオでは、影響分析がタイムリーに実行されるかどうかを事前に把握し、このタイプの再編成を有効にしない選択肢があると便利です。
そのために、GeneXus は影響分析にさまざまな検証を導入しており、このようなケースをレポートしたり、発生したときに停止したりすることができます。
影響分析レポートには、テーブルに対して実行された再編成が、現在のプログラムと「下位互換性なし」であるかどうかが表示されます。
「情報」セクションに次のメッセージが表示されます:「nfo0003: The reorganization for this table makes the schema not backward compatible. (このテーブルの再編成により、スキーマの下位互換性が失われます)」(対応する説明も表示されます)。
たとえば、本番環境に次のように構成された「Customer」というトランザクションがあるとします (v1):
これらの変更は、新しい現実を表すために構造 (v2) に適用されます:
次の点に注目してください:
- 2 つの新しい項目属性 CustomerFirstName および CustomerLastName が追加されています。
- CustomerName が削除されています。
影響分析レポートには次の情報が表示されます:
これらの変更に下位互換性がないことを示しています。
したがって、現在のプログラム (v1) が引き続き新しいスキーマ (v2) で動作する必要がある場合、この再編成を行う前に実行する必要のあるアクションがいくつかあります。たとえば、新しい項目属性
CustomerFirstName および
CustomerLastName を Null 許容 ( [ Nullable ] = Yes) に設定します。
以下は、GeneXus による互換性の制御です:
ケース |
変更内容 |
Null でない項目属性 %1 を追加する
|
新しい項目属性 %1 を [ Nullable ] = No で追加
|
テーブル %1 の名前を変更する
|
テーブル %1 の名前を変更
|
項目属性 %1 の Null 許容を削除する
|
項目属性 %1 の [ Nullable ] プロパティの値を「No」に変更
|
項目属性 %1 を削除する
|
項目属性 %1 をテーブルから削除
|
テーブル %1 を削除する
|
テーブル %1 を削除
|
項目属性 %1 の名前を変更する
|
項目属性 %1 の名前を変更
|
項目属性 %1 のタイプを変更する
|
項目属性 %1 のデータタイプを変更
|
項目属性 %1 の長さ/小数点を変更する
|
Numeric タイプの項目属性 %1 の長さを変更
|
項目属性 %1 の長さを短くする
|
Numeric タイプの項目属性 %1 の長さをより短い長さに変更
|
主キーの構成を変更する
|
テーブルの主キーの構成を変更
|
一意性制約 %1 を追加する
|
テーブルのインデックス %1 から新しいキー候補を作成
|
外部キーの制約 %1 を追加する
|
新しい整合性制約を意味する新しい外部キーを追加
|
レポートするケースを決定するための設計基準として、上記のシナリオが検討されました。次の場合にケースがレポートされます:
- v1 のプログラムで SQL エラーを生成する場合。たとえば、項目属性が削除される場合、アクセスの試行時に v1 のプログラムで「無効な列です」という内容のエラーが発生します。
- v1 のプログラムのナビゲーションで大きなリスクが生じる場合。たとえば、「主キーの構成を変更する」は必ずしも SQL エラーを生成するわけではありませんが、古いプログラムが予期したとおりにナビゲートせず、データの整合性が損なわれます。
通知を受けるだけでなく、これらの再編成を停止するには、「nfo0003」のメッセージを
[ Warnings treated as errors ] プロパティのリストに含める必要があります。
GeneXus 17 Upgrade 5 以降
再編成機能の詳細