型進化に関する考慮点

9.11.1 型の変更のクライアントへの送信

ある型がサーバー側で進化すると、この型を使用するすべてのクライアント・アプリケーションで、この型に対応付けられている構造体の変更が必要になります。この変更は、OTTまたはJPublisherを使用して実行できます。

また、構造体の変更に伴ってプログラムの変更が必要な場合もあります。このような変更を行った後、アプリケーションをコンパイルしなおし、再リンクする必要があります。

サード・パーティ・アプリケーションのリリース間で型が変更される場合があります。サード・パーティ・アプリケーションの最新リリースとの互換性を確立するために再コンパイルする必要があることをクライアント・アプリケーションに通知するには、リリース指向互換性初期化ファンクションをクライアントからコールします。

このファンクションは、クライアント・アプリケーションのどのリリースを使用しているかを示す文字列を入力として受け取ることができます。リリース文字列が最新バージョンと一致しない場合は、エラーが発生します。その場合、クライアント・アプリケーションは、最新リリースとの互換性を確立するための変更の一環として、リリース文字列を変更します。

次に例を示します。

FUNCTION compatibility_init(
 rel IN VARCHAR2, errmsg OUT VARCHAR2)
RETURN NUMBER;

ここで、

relは、リリース10.1など、製品によって選択されるリリース文字列です。
errmsgは、戻す必要のある任意のエラー・メッセージです。
このファンクションは、成功すると0(ゼロ)を戻し、エラーの場合は0(ゼロ)以外の値を戻します。

9.11.2 デフォルトのコンストラクタの変更について

型が変更されると、新しく追加された属性をパラメータ・リストに含めるためなどに、デフォルトでシステム定義されたコンストラクタを変更する必要があります。デフォルトのコンストラクタを使用している場合は、コールをコンパイルするためにプログラム内の起動を変更する必要があります。

システム定義されたデフォルトのコンストラクタではなく、独自でコンストラクタ・ファンクションを定義して使用する場合は、コンストラクタのコールを変更する必要はありません。「ユーザー定義コンストラクタの利点」を参照してください。

9.11.3 型のFINALプロパティの変更について

型T1を、FINALからNOT FINALに変更した場合、クライアント・プログラムにある型T1の属性はすべて、インライン構造体からT1へのポインタに変更されます。したがって、この属性がアクセスされた場合に参照解除を使用できるようにするには、プログラムを変更する必要があります。

逆に、型をNOT FINALからFINALに変更すると、その型の属性はポインタからインライン構造体に変更されます。

たとえば、型T1(a int)とT2(b T1)があるとします。ここで、T1のプロパティはFINALです。T2に対応するC/JAVA構造体はT2(T1 b)です。ところが、T1のプロパティをNOT FINALに変更すると、T2の構造体はT2(T1 *b)になります。