Caché 2011.1

ライセンス

以前のバージョンでは、$USERNAME が UnknownUser である場合、CSP セッションに対してライセンス数が消費されることはありませんでした。現在は、Caché ライセンス・キーで Web アドオン機能が有効化されている場合、ライセンス・キーの消費を避けるには Web アプリケーションを明示的にパブリックとして宣言する必要があります。そうしないと、CSP セッションおよび SOAP セッションが 1 ライセンスを消費します。

これは、CSP アプリケーションの場合、%CSP.SessionEventsOpens in a new tab クラスのサブクラスを作成し、OnStartSession イベントを処理するメソッドを定義し、$SYSTEM.License.PublicWebAppUser() をそれから呼び出すことによって実現できます。

また、現在は、匿名 SOAP 要求 (Caché ログインが発生しないもの) が、最短 10 秒間で 1 ライセンスを消費します。アプリケーションを変更する必要はありませんが、Caché から SOAP 要求を処理する場合は追加のライセンスの購入が必要になることがあります。

$SYSTEM.License.Login(LicenseId) を CSP サーバ・プロセスまたは SOAP Web サービス・プロセスから呼び出すと、Caché サーバ・プロセスに対して 1 ライセンスが不適切に消費されます。 このライセンス・ユニットがサーバ・プロセスではなく CSP または SOAP セッションに関連付けられているのは、後続の要求が異なる Caché プロセスによって処理される可能性があるためです。

$SYSTEM.License.Login(LicenseId) API は、Caché サーバ・プロセスに関連付けられた 1 ライセンスを消費します。 この API を CSP または SOAP サーバ・プロセスから呼び出すと、事実上、セッション用とプロセス用にそれぞれ 1 つずつ、2 つのライセンス・インスタンスが作成されます。 プロセス・ライセンス・インスタンスは、プロセスが終了しない (このようなことは通常ありませんが) 限り解放されません。 CSP セッションのライセンス識別子を明示的に指定するには、%CSP.Session:Login メソッドを呼び出してください。

読み取り専用でマウントされる 2K データベース

このリリース以降、2K データベースは Caché から書き込み可能としてマウントされることはなくなります。これは、発表済みの 2K データベースのサポートの廃止における次の段階です。2K データベースにデータを書き込む場合は、データを 8K 形式に変換する必要があります。メソッド ##class(SYS.Database).Copy()Opens in a new tab を使用すると、データベースを長い形式に変換できます。

構成ファイルへの変更

次の 2 つのパラメータが .cpf ファイルに追加されました。

• LibPath パラメータが [config] セクションに追加されました。

  これは、Unix® に対してのみ使用され、これによってサードパーティ製共有ライブラリの検索に使用される LD_LIBRARY_PATH 環境変数が設定されます。Windows および OpenVMS では無視されます。これは、必須の長さや最大長がない文字列プロパティです。この設定は直ちに有効になり、システムを再起動する必要はありません。

• QueryProcedures パラメータが [SQL] セクションに追加されました。

  これは、クエリの SqlProc 設定に関係なく、すべてのクラス・クエリが SQL ストアド・プロシージャとして投影されるかどうかを定義します。既定値は 0 です。SqlProc=1 で定義されているクラス・クエリのみがストアド・プロシージャとして投影されます。1 に設定すると、すべてのクラス・クエリがストアド・プロシージャとして投影されます。 この設定は直ちに有効になり、システムを再起動する必要はありません。ただし、この変更を有効にするには、クラス・クエリを含めてクラスを再コンパイルする必要があります。

• [Debug] セクションで dumpstyle=3 を設定すると、共有メモリがコア・ダンプに含まれなくなります。

監査レコードにオペレーティング・システムのユーザ ID が含まれる

このリリース以降、ユーザ名が監査レコードの一部となっています。表示されるときには、16 文字までに切り捨てられます。

実際のオペレーティング・システムのユーザ名は、UNIX® または OpenVMS システムに接続している場合にのみ返されます。Windows では、コンソール・プロセスのユーザ名が返されます。telnet の場合はそのプロセスの $USERNAME が返されます。クライアント接続の場合は、クライアントのユーザ名が含まれます。

リカバリ時の必須データベースのマウントの失敗は致命的エラーになる

以前のリリースでは、Caché のリカバリの際は、マウントに失敗した必須データベースはスキップされ、処理が継続されました。しかし、その後の起動で、cache.cpf のデータベース・セクションを処理するときに失敗し、そのインスタンスがシャットダウンしていました。このバージョンでは、Caché のリカバリ中に必須データベースのマウントに失敗すると致命的エラーとなり、起動はその時点で中止されます。これにより、根本的な問題に、より早く対処できます。

タスク・マネージャのジョブで追加の IP アドレスが使用される

Cache タスク・マネージャを使用して開始された顧客のタスクでは、ライセンス識別子として Run As ユーザ名が使用されます。 バージョン 2010.1 以降、Caché では、そのようなジョブのユーザ名にピア IP アドレスを追加していました。 ただし、タスク・マネージャによって開始されたプロセスにはピア・アドレスはなく、アドレスは追加されませんでした。 これにより、タスク・マネージャによって開始されたジョブと、その他の方法で開始されたジョブとの間でライセンスの消費に不整合が発生していました。 このリリース以降、タスク・マネージャによって開始されたジョブには、ローカル IP アドレスが追加されます。

緊急のログイン・ポリシー

このバージョンでは、緊急ログイン・ポリシーが 2 要素認証に対応するように拡張されています。このポリシーは、以下のとおりです。

1. 緊急アクセス中には、緊急ユーザのみがログインできます。有効になっているサービスは、コンソール、ターミナル、および CSP のみです。

2. 有効なサービスに対しては、認証されたアクセスのみが許可されます。該当のサービスに対しては Caché 独自のパスワード認証が使用されるので、緊急ユーザのユーザ名とパスワードを使用する必要があります。

3. アプリケーションにカスタム・ログイン・ページがある場合は、そのページが緊急ログイン中に使用されます。

4. /csp/sysアプリケーションの場合、使用可能なカスタム・ログイン・ページがあっても、緊急アクセス中は標準ログイン・ページ (%CSP.Login.cls) が使用されます。システム既定値を使用すると、ユーザが緊急モードで管理ポータルにアクセスできることが保証されます。

5. 2 要素認証は、緊急アクセス・モードでは無視されます。緊急ユーザは 2 要素認証が有効になっているアプリケーションにはアクセスできなくなります。

アップグレード時における照合チェック

このバージョンでは、アップグレード・インストール中に、新しいメソッド ##class(SYS.Database).FixDefaultGlobalCollation(Directory)Opens in a new tab が、インスタンスで定義されている、そのインスタンスによってマウント可能なすべてのユーザ・データベースに対して実行されます。このメソッドにより、システム・グローバルの照合におけるエラーはすべて cconsole.log に報告されます。

エラーが検出された場合、ユーザは、プログラマ・プロンプトからメソッドを再度実行し、データベースの修正フラグを 2 番目の引数Opens in a new tabとして渡す必要があり、これによってグローバルが正しい順序で再照合されます。

ジャーナル・デーモンがハングした時のシステムのフリーズ

ジャーナル・エラーの発生時にフリーズするシステムでは、書き込むジャーナル・データが存在する場合に Caché 制御プロセスがジャーナル・デーモン (JD) のハング (10 秒間動作しない状態) を検出すると、ライト・デーモンを停止するため、システムはフリーズします。

すべてのプラットフォーム

弊社の製品と共に構築およびインストールされる OpenSSL ライブラリはバージョン 1.0.0b にアップデートされました。OpenSSL に依存するすべての InterSystems プロジェクトは新しいバージョンを使用するようにアップデートされました。

FOP は、アラビア語での処理専用の InterSystems のパッチが含まれたバージョン 1.0 にアップデートされました。

Mac OS X — JOB コマンドの変更

Mac OS X 上の JOB コマンドのメカニズムが変更されました。これにより、問題は解決しますが、副次的作用が発生する場合があります。基盤となるカーネルと Mac OS X プロセスとの対話方法および GUI セッションの存在のため、従来の UNIX® のデーモン作成方法 (fork/exec) では、Mac OS X に対して不十分です。Apple 社は、launchd (またはそのユーザ・インタフェースである launchctl) を使用してすべてのバックグラウンド・デーモンを起動することを推奨しています。

このリリースでは、この推奨事項が実現されています。Mac OS X 上の JOB コマンドでは、launchctl が呼び出されて Caché JOB が起動されます。

AIX — 直接 I/O 処理の変更

AIX システム上でデータベース、ジャーナル・ファイル、および WIJ (またはそのいずれか) を “直接 I/O” のために開く場合、Caché では直接 I/O ではなく同時 I/O のためにファイルを開く O_CIO オプションが使用されます。O_DIRECTIO の使用により他のものによって開くことが可能になり、他のプロセスがバッファ I/O を使用している場合に問題が発生することがあります。

OpenVMS

• $ZF への変更

  OpenVMS では、ユーザ指定 $ZF() 関数は C と MACRO のいずれでも作成できます。2 つの異なるヘッダ・ファイル (cdzf.h と czf.m64) の間での PRIV と NOPRIV の定義の不一致のために、czf.m64 の PRIVS=YES 機能は、あるべき設定とは反対に設定されていました。 PRIV/NOPRIV 機能に依存する C で作成されたユーザ $ZF() 関数は、再コンパイルする必要があります。

• コンパイラ・バージョンに対する変更

  サポート要件のために、OpenVMS コンパイラが変更されました。現在はバージョン 7.2 です。以前のコンパイラでビルドされた実行可能ファイルは、新しいランタイムと互換性がありません。

  つまり、Xalan および Xerces の再コンパイルが必要でした。インターシステムズでは、この機会を利用して Xalan をバージョン 1.10 に、Xerces をバージョン 2.7 にアップグレードし、それらをライブラリ (.olb) として組み込み、実行可能ファイルにコンパイルしたため、個別に配布されることはなくなりました。

• Xalan、Xerces、および unixODBC に対する変更

  コンパイラ・バージョンにおける変更のため、Xalan、Xerces、および unixODBC の再コンパイルが必要でした。インターシステムズでは、この機会を利用して Xalan をバージョン 1.10 に、Xerces をバージョン 2.7 にアップグレードし、それらをライブラリ (.olb) として組み込み、実行可能ファイルにコンパイルしたため、個別に配布されることはなくなりました。

  unixODBC の OpenVMS バージョンは、バージョン 2.2.12 にアップグレードされました。これは、他のプラットフォームによって使用されるものと同じです。

• Informix SQL コンバータはサポートされていない

  Informix から Caché への SQL コンバータは OpenVMS ではサポートされていません。OpenVMS システム上で Informix 変換を実行しようとすると、コンソール・ログにメッセージが記録される代わりに、エラーになります。

• SHA-2 関数が OpenVMS の 8.4 より前のバージョンで使用できない

  OpenVMS 8.2-1 および 8.3 では、関数 $System.Encryption.RSASHASign() および $System.Encryption.RSASHAVerify() は、224、256、384、または 512 ビットのビット長を使用している場合は SHA-2 ハッシュ関数をサポートしません。これらのリリースで HP が提供する OpenSSL ライブラリは、OpenSSL 0.9.7e を基盤としており、それには SHA-2 関数のサポートが含まれていません。

• バックグラウンド JOB に対するクォータのアップグレード

  このバージョンでは、ジョブ化されたプロセスに対する OpenVMS プロセス・クォータのいくつかの既定値が更新されました。 主要なものは PGFLQUOTA です。これは、仮想メモリの割り当てを制限し、サイズが非常に大きい XML ファイルを処理する際に問題がありました。BYTLM および FILLM も最近のベンダの推奨事項に合わせて引き上げられました。

Windows — インストーラの変更

IIS 仮想ディレクトリ /csp が既に構成済みであることがインストーラによって検出されると、その IIS 構成データは更新されなくなります。

さらに、Apache および IIS の更新を制御するため、次の新しいプロパティが定義されました。

• CSPSKIPIISCONFIG

• CSPSKIPAPACHE20CONFIG

• CSPSKIPAPACHE22CONFIG

これらのいずれかを 1 の値に設定すると、対応する CSP バイナリ・ファイルのインストールの更新が実行されますが、対応する Web サーバ構成に対する変更は行われません。このプロパティを 0 に設定すると、/csp 仮想ディレクトリの存在に関係なく、インストーラによって適切な Web サーバ構成が更新されます。

大規模なルーチンをサポートするためのコンパイラ・バージョンの変更

内部コンパイラのバージョンが大きくなり、大規模なルーチンをサポートするためのオブジェクト・コードでの変更が反映されました。 これは、このバージョンでコンパイルされたルーチンおよびクラスは、前のバージョン上にコピーして実行できないことを意味します。これを試みると <RECOMPILE> エラーが発生します。

Caché の完全修飾されたドメイン名と Kerberos

Kerberos サーバのプリンシパル名の一般的な形式は、RFC 4120、Kerberos V5、セクション 6.2.1 で指定されています。このプリンシパル名は、いくつかの部分で構成されています。この構成は以下のとおりです。

• サービス名

• “/”

• ホストのインターネット・ドメイン名

• “@”

• サーバが登録されている鍵配布センター (KDC) のレルム

そのような名前の例は、cache/oakland.iscinternal.com@ISCINTERNAL.COM です。

前のバージョンでは、Windows 以外のプラットフォーム上の Caché への非ターミナル接続に対する Kerberos 認証では、不明確な形式 (cache/host@KDC-realm) が使用されており、これは csession で Caché にアクセスする場合の使用法と互換性がありませんでした。このバージョンでは、Caché は、常に正しい形式のサービス・プリンシパル名を生成するように変更されました。

多くの場合、これによる影響はありません。それは、大多数のサイトではインスタンスのキータブでサーバ・プリンシパル名を定義するときに FQDN 形式が使用されると考えられるためです。ただし、いくつかのサイトでは、ホスト oakland に対して値 cache/oakland@ISCINTERNAL.COM が定義されるなど、ホスト名のみを使用したサーバ・プリンシパル名が定義されている可能性もあります。これらのサイトでは、このリビジョンを含む Cache のバージョンにアップグレードした後に問題が発生します。

このエラーを訂正するには、そのサーバ・プリンシパルの keytab エントリを作成します。この例では、非標準の cache/oakland@ISCINTERNAL.COM に代わる cache/oakland.iscinternal.com@ISCINTERNAL.COM を作成する必要があります。

ECP でジョブ ID の代わりにプロセス ID が使用されるようになる

このリリースでは、ジョブがスレッドではない場合、ECP はジャーナル・エントリにジョブ ID の代わりに PID を記録するようになります。これは、ECP セッションが下位互換性を持たなくなることを意味します。ミラー構成またはクラスタ構成では、マスタの新しいバージョンから、製品の以前のバージョンにフェイルオーバーすることはできません。

シャドウイングの開始には開始イベントが必要とされる

管理ポータルで、または ^SHADOW を使用してシャドウを開始する場合、ユーザはシャドウイングを開始するソース・イベントを選択する必要があります。これは、シャドウ構成オブジェクトの StartPoint プロパティの値に関係なく必要です。このオブジェクトはこの変更の時点で廃止されています。シャドウを非対話形式で開始するには、常に ##class(SYS.Shadowing.Shadow).Start()Opens in a new tab メソッドの StartPoint パラメータを指定する必要があります。

シャドウ情報が CPF ファイルに含まれるようになった

2011.1 以降のバージョンにアップグレードするとき、定義済みのシャドウ・システムが存在する場合は、そのシャドウ情報が変換され、CPF ファイルに移動されます。 CPF ファイルには次の 2 つの新しいセクションが含まれるようになりました。

• [Shadows] セクション。シャドウの名前およびプロパティを定義します。

• [MapShadows.NAME] セクション。シャドウ・ディレクトリ・マッピングが含まれます。

グローバルのエクスポートにおいて名前の形式がチェックされない

%Library.Global.Export() に依存して “.gbl” で終了していない名前を拒否するアプリケーションは、予期したとおりに機能しなくなる可能性があります。その接尾語で終わっていない名前は受け入れられ、それらの名前を持つグローバルが存在する場合はエクスポートされるようになります。存在しない場合は、エクスポートから除外されますが、エラーは生成されません。$SYSTEM.OBJ.Export() を使用できます (呼び出し側で “type” を必要とする場合)。

%GSIZE 出力形式の変更

%GSIZE 出力を解析し、固定数の列を予期するアプリケーションでは問題が発生する可能性があります。出力における列の数は、現在 %GSIZE の指定した実行に対しては、定数ですが (以前は変数)、列の数は出力における最も長いグローバル名のサイズに応じて、実行ごとに変わることがあります。%GSIZE 出力を解析するのではなく、アプリケーションでは %SYS.GlobalQueryOpens in a new tab の Size クエリを使用してグローバル・サイズ情報を取得する必要があります。

複数のコンパイルに対してオンになるジャーナリング

以前のバージョンでは、Caché は、ジャーナル・ファイルが一杯になってしまうことを回避し、コンパイル速度のわずかな向上のためにクラス・コンパイルの実行中は既定でジャーナリングが無効化されていました。複数コンパイルなどクラス・コンパイラにおける最近の変更のため、これは不要になりました (ミラーリングを使用する場合は望ましい)。

このバージョン以降、既定でクラス・コンパイルはジャーナリングされます。これにより、多数のクラス・コンパイルが実行される場合、ジャーナル・ファイルに多くのデータが追加されるようになります。開発システムでは、管理者は、既定の /journal 修飾子の設定を変更し、ジャーナリングの無効化を検討することが必要な場合があります。本番システムでは、管理者が新しい既定であるクラス・コンパイルのジャーナリングを必要とすることはほぼ確実です。

ライブラリ・パスが cache.cpf の一部となる

ユーザごとに LD_LIBRARY_PATH を使用すると、ルート・レベルでコードを実行する可能性があるスプーフィングを招くおそれがあります。このバージョン以降、LD_LIBRARY_PATH データは cache.cpf の一部となります。<install_directory>/bin 以外では、cache.cpf の LibPath フィールドに含まれているものを除いてセッションに対する現在のライブラリの検索パスには何も設定されません。このフィールドは管理ポータルを使用して更新可能になります。LD_LIBRARY_PATH 環境変数に依存して、サードパーティ製共有ライブラリの検索パスを設定するすべてのアプリケーションが影響を受けます。

デバイス・エイリアスは一意である必要がある

このリリースでは、デバイスに対して指定されたエイリアスがチェックされます。複数のデバイスに対して同じエイリアスが使用されている場合、Caché によって起動時にエラーが報告され、2 番目の定義は無視されます。

緊急起動に対する変更

緊急起動はこのバージョンで次のように拡張されています。

• TASKMGR は起動されません。

• シャドウイングは起動されません。

• Ensemble プロダクションは起動されません。

• ミラーリングは起動されません。

• ZSTU、%ZSTART、%ZSTOP、ZSHUTDOW は、システムの起動時にも停止時にも実行されません。

• 緊急 ID を使用してログインするユーザ・プロセスは %ZSTART も %ZSTOP も実行しません。

さらに、CPF ファイルの STU=1 パラメータは削除されました。メンテナンスのためにシステムを起動する必要がある場合は、緊急起動オプションを使用します。

向上したキー管理

このバージョン以降、キー・ファイルを管理するためにデータベースまたはマネージド暗号化キーを有効にする必要はなくなります。 ただし、新しい管理者をキー・ファイルに追加したり、起動時に無人でデータベース・キーを有効にするように構成するには、有効な暗号化キー・ファイル管理者ユーザ名とパスワードを知る必要があります。

TROLLBACK でデータベース・マウントは開始されない

Caché の一般的な原則の 1 つは、データベースが明示的にディスマウントされている場合、データベースのアクセスの試みによってそれが暗黙的にマウントされないことです。オペレータの操作によって明示的にマウントする必要があります。 TROLLBACK は、この原則と一貫性を保つように訂正されました。

新しいロケール

Slovenian ロケール用の新しい照合を使用できます。Slovenian2 は大文字と小文字が一緒に照合される点 (大文字小文字のマージ) を除いて Slovenian1 に似ています。

Unicode Turkish ロケールを使用できます (“turw”)。既定では、Turkish1 照合が使用されます。

VARCHAR(Max) および NVARCHAR(Max) に対する新しい DDL データ型マッピング

Caché のこのバージョン以降、VARCHAR(Max) および NVARCHA(Max) に対して新しい既定のシステム定義 DDL マッピングが追加されています。これらはどちらも %Stream.GlobalCharacter にマッピングされます。 この変更を含むバージョンを入手する前に、単にシステムによってユーザ定義 DDL マッピングにこれらのマッピングを追加できます。この変更により、VARCHAR(Max) および NVARCHAR(Max) を TSQL CREATE PROCEDURE DDL 文のプロシージャに対する引数として使用できます。

大規模ルーチンに対するサポート

このリリース以降、コンパイラは最大で長さ 8MB までのルーチンを処理できます。 コンパイル済みルーチンが 32KB を超える場合、Caché では、このルーチンを保持するために最大 128 個の 64KB ルーチン・バッファが使用されます。これらのバッファは 1 つのユニットとして割り当てられ、管理されます。したがって、このリリースでコンパイルされる大規模なルーチンの使用は、ルーチン・バッファの割り当てに影響を与えます。一般的に、前のリリースよりも多くの 64KB バッファが必要になります。ただし、バッファ・プール間でのメモリの分散は、特定のサイトで使用中のルーチン・サイズのリアルタイムの分散に依存するようになります。

日本の日時形式の実装

2 つの新しい日付形式が $ZDATE および関連する関数の dformats リストに追加されました。

• 16 – 年、月、および日の値の後に、年、月、日を表す日本語の漢字がそれぞれ続きます。つまり、YYYY$CHAR(24180)MM$CHAR(26376)DD$CHAR(26085) となります

  。

• 17 – 形式 16 の場合と同様で、年を表す文字の後と、月を表す文字の後にスペースが 1 つずつ追加されます。

Latin1 以外の 8 ビット文字セットに対する URL 変換をシンメトリックにする

Latin1 に基づいていない 8 ビット・ロケール (例えば CP1251 ベースの Russian ロケールである “ruw8”) の場合

$ZCVT("%XX", "I", "URL")

では、XX を現在の文字セットの文字の 16 進コードとして解釈します。以前のリリースでは、これは Unicode 文字であると想定されていました。いくつかの文字セットでは、このコードポイントは、現在の文字セットで対応する値がなく、“?” などの既定の文字で置換されていました。

新しい動作は、CP1251 の場合

$ZCVT($C(192), "O", "URL") = "%C0"

および

$ZCVT("%C0", "I", "URL") = $C(192)

は、すべての文字に対して、URL 変換を使用したラウンド・トリップを有効にすることを意味します。

大規模なクラスの制限

このリリースから、大規模なクラス記述子がサポートされるようになりました。つまり、このクラスで宣言される多数のメンバをクラスがサポートできます。クラス継承階層の上限、および許可されるスーパークラスの数も定義されました。該当する結合の一覧については、"Caché プログラミング入門ガイド" の “一般的なシステム制限” を参照してください。

エラー・レポートの変更

エラーを返すための標準 Caché メカニズムでは、標準メッセージと共に $$$ERROR マクロを使用します。多くの場合、メッセージには、エラーの説明のみが含まれ、コンテキスト情報は含まれていませんでした。“ロードするオブジェクトが見つかりません” メッセージなどのいくつかのメッセージには、エラーが検出されたクラス名が含まれるようになります。いくつかの SQL ストレージ・アプリケーションは、この新しい形式を認識するために変更が必要になる可能性があります。

クラス・ディクショナリのレベル 25 への更新 (LegacyInstanceContext)

Caché のこのバージョンによって、クラス・ディクショナリのバージョンがレベル 25 に更新されます。変更点の中で特にここでは LegacyInstanceContext クラス・キーワードが導入されます。このキーワードは、%this を最初の引数としてインスタンス・メソッドに渡す生成済みコードにクラスが依存することを示すものです。これは、"Compatibility BlogOpens in a new tab" で 2009 年にすでに発表されていました。

補助的に、クラス・ディクショナリのアップグレードでは、%this への参照が検索されます。誤検出となる可能性があるにもかかわらず、$XECUTE および $TEXT が使用されている場合に備えて、コードとコメントの両方がスキャンされます。何らかの該当する参照が検出された場合、クラスは LegacyInstanceContext が必要としてマークされるため、コンパイラは引き続き %this を最初の引数としてインスタンス・メソッドに渡すためのコードを生成します。

%this のインスタンスが検出されなかった場合、クラスは LegacyInstanceContext としてマークされないため、インスタンス・メソッドは %this が最初の引数として渡されると見なさなくなります。

ただし、この方法では、%this が存在して適切に設定されていると仮定する別のコードは見つかりません。次のような外部ルーチンを呼び出すメソッドを持つクラスについて考えてみましょう。

method Test()
{
    Quit $$Func^Routine()
}

Routine は、以下のとおりです。

Func () public {
    Quit %this.Name
}

このクラスの検索では %this の使用は検出されない (そのソースの外側にある) ため、このクラスは LegacyInstanceContext としてマークされません。後続の実行で <UNDEFINED> エラーが発生する可能性があります。また、デバッグがはるかに困難な状況では、%this が間違ったコンテキストをポイントする場合や、まったくオブジェクト・インスタンスをポイントしない場合も考えられます。

新しいコードはすべて、コンテキストを $this に依存します。%this は非推奨となったため、新しいクラスに対して設定されなくなります。LegacyInstanceContext=1 としてマークされたすべての古いクラスは、引き続き以前のリリースと同様に動作します。

LegacyInstanceContext のために既存のクラスを変更する必要はありません。ただし、クラスを更新する場合、その手順は以下のとおりです。

1. 指定したアプリケーションの %this のすべての出現を $this で置き換えます。

2. LegacyInstanceContext キーワードをプロジェクトまたはアプリケーションのすべてのクラスから削除します。

3. アプリケーションを再コンパイルします。

クラスの削除

2010.2 バージョンに存在していた以下のクラスは、今回のバージョンで除外されています。

• %CSP.UI.Portal — ObjectGatewayStartStop

• %ExtentMgr — Extent

• %Library — CppApi

• %OSQL — Debugger、Transformer

• %SQL — Routine、RoutineColumn

• %Studio.SourceControl — ISCCheckin

• %WebStress — DataTransfer、Page

• %WebStress.UI — GridDetails、Attributes、Columns、SelectOptions、Tags、Transfer、SaveData

• %WebStress.UI — Input、Menu、Previous、Definitions、Root、Search、Criteria、Displays、SearchPage

• %XML — SupportCode

• %ZEN.Report — sort

• %cspapp.op — webstress、appservers、appsystem、blank、encrypt、generators、nopagedelay、noresultstore、proxysetupmozilla、proxysetupmsie、scriptedit、scriptrecorder、scriptrecorderstatus、showerrors、showurls、testappstats、testedit、testprint、testrun、visual、visualdisplay、visualdisplayoptions、webservers

• SYS.Info — Advertiser

• com.intersys.jdbcgateway — JDBCGateway

• java.io — InputStream、OutputStream、Serializable

• java.lang — Class、ClassLoader、Object、Package、AccessibleObject、Constructor、Field、Member、Method

• java.net — ContentHandler、ContentHandlerFactory、FileNameMap、URL、URLConnection、URLStreamHandler、URLStreamHandlerFactory

• java.security — CodeSource、Guard、Key、Permission、PermissionCollection、Principal、ProtectionDomain、PublicKey、Certificate

• java.util — Collection、Enumeration、Iterator、Map、Set

クラス・コンポーネントの削除

このバージョンでは、以下のクラス・コンポーネントが、以前に存在していたクラスから移動または削除されています。

メソッド返り値の変更

今回のバージョンの Caché では、以下のメソッド返り値が変更されました。

• %CSP.UI.System.Index — ProcessIndexZen

• %Library.ProcedureContext — AddContext

• %SYSTEM.Encryption — RSAEncrypt

• %UnitTest.TestCase — AssertSkippedViaMacro、AssertStatusNotOKViaMacro、AssertStatusOKViaMacro

• %WebStress.Control — StartMonitor

• %ZEN.Datatype.boolean — XSDToLogical

• %ZEN.Report.Version — getVersion

メソッド・シグニチャの変更

今回のバージョンの Caché では、以下のメソッドの呼び出しシーケンスが変更されました。

%Library.Decimal は既定で Scale=0 に設定される

Caché データタイプ %Library.DecimalOpens in a new tab は、既定で SCALE=0 になります。以前のリリースでは、既定の SCALE はありませんでした。INSERT/UPDATE またはオブジェクトの保存時に、Normalize メソッドは SCALE が指定されていない場合は既定の SCALE=0 に丸め、それ以外の場合はそのプロパティに丸めます。

同一クラスの複数のメソッドに同一のラベルが含まれている

クラスをコンパイルする一貫として、コンパイラはクラスのできる限り多くのメソッドを 1 つのコンパイル・ユニットにパックしようとします。そのクラスの 2 つ以上のメソッドで同じ名前のラベルが定義されており、それらのメソッドが PROCEDUREBLOCK = 0 としてマークされている場合、コンパイラがそれらのメソッドを同じコンパイル・ユニットに含め、重複ラベル・エラーを報告するリスクがありました。

クラス・コンパイラの最近の改善でコンパイル・ユニットのサイズが拡大されたため、同じラベルを持つ非プロシージャ・ブロックのメソッドによって、このエラーがトリガされる可能性が高まりました。アプリケーションによってこの状態がトリガされる場合は、プロシージャ・ブロックを使用するか、重複が起きないようにラベルの値を変更するようにアプリケーションを記述する必要があります。

サブクラス内でスーパークラスから継承されたプロパティの重複を回避する

以前は、アプリケーションがプロパティ X をスーパークラスで定義した後、プロパティ X を一切変更しない (スーパークラスから継承するだけの) サブクラスを作成した場合、クラス・コンパイラは、そのプロパティをサブクラスのクラス記述子内で再定義していました。これは、Caché がクラス・コンパイラによってそのプロパティを参照するために内部スロット番号を必要としたためです。この要件は廃止されました。Caché では、サブクラス内でのプロパティの重複が回避され、システム・コードがスーパークラスから動的にプロパティを継承することが可能になりました。

ユーザが ID 値を正規化する必要がある

このリリース以降は、非正規化された整数を %Open、%OpenId、%Exists、および %ExistsId に渡しても機能しません。そのような値を渡すアプリケーションは、メソッドを呼び出す前に正規化を適用する必要があります。

単純 ID 値は、ID をパラメータとして取るさまざまなメソッドによって正規化されなくなりました。クラスのさまざまなメソッドに渡される ID 値は、<OREF>.%Id() メソッドで返される正規化された形式であることが想定されています。ID は単純な整数であるが、渡される値が整数の正規化された形式ではない (例えば、01 と 1 である) 場合、ここに示すメソッドは失敗します。

SQL ストレージ・コンパイラで SQLCHILDSUB 名が認識される

PARENT のカーディナリティとのリレーションシップを定義するクラスは、多くの場合、"子クラス" と呼ばれ、そのリレーションシップのタイプ・クラスは "親クラス" と呼ばれます。子クラスの ID は、リレーションシップ (その親の ID) と、プロパティ値またはシステムによって割り当てられた値に基づいています。ID がシステムによって割り当てられた値に基づいている場合、子クラスによって投影される SQL テーブルに列が生成されます。その生成された列は、システムによって割り当てられた値に対応しており、“childsub” と呼ばれます。既定では、これが生成された列の名前になります。

この名前は、ストレージ定義の SQLCHILDSUB キーワードに名前を入力することで、ストレージ定義で指定できます。childsub (オブジェクトの場合は ID) に値を割り当てるためにシステムによって使用される式は、SQLIDEXPRESSION キーワードで定義されます。

以前のリリースでは、既存の子クラスが SQLCHILDSUB を定義済みで、そのクラスをこのリリースの前にコンパイル済みである場合、生成される childsub 列の名前は “childsub” になります。今回のリリース以降は、SQLCHILDSUB の値が使用されます。これは、下位互換性がないことを示しています。以前の動作はエラーの結果であり、新しい動作は正常です。これに対する一般的な回避策は、childsub を表すプロパティを定義することでした。これが行われると、この変更の影響はなくなります。

カーディナリティ・リレーションシップが REQUIRED を適用できない

以前は、MANY または CHILDREN のカーディナリティを持ち、かつ REQUIRED を指定するリレーションシップは、正常にコンパイルされました。現在は、n カーディナリティ・リレーションシップに対する REQUIRED 制約はサポートされていないことを示すエラーがコンパイラから報告されます。

正常にコンパイルするには、REQUIRED 制約を削除します。

複数のジョブを使用するコンパイル

このバージョン以降、Caché は、大規模なコンパイルに対して複数ジョブを使用する機能を提供します。これは、修飾子 /multicompile を使用して有効化されますが、既定では無効化されています。

これが有効化されており、コンパイラが、複数ジョブを有効に使用できることを検出した場合は、%occCompileUtils ルーチンの場合のように、%SS に表示されるスレーブ・ジョブを開始します。これは、グローバルおよび $SYSTEM.Event を使用してこれらのスレーブ・ジョブと通信し、いくつかのワークを実行する必要があることを通知します。スレーブ・ジョブが完了すると、表示するエラー情報または出力と共に、ワークが完了したという情報をメイン・プロセスに返信します。一般的な動作では、ワーカ・ジョブが開始され、ワークがキューに格納され、ワーカ・ジョブがそのワークの担当部分を処理します。メイン・プロセスは、各ジョブが完了するまで待ち、表示するエラーやその他の出力があれば表示します。すべてのワークが完了すると、メイン・プロセスが繰り返し処理され、残りのワークのキューへの格納が再び開始されます。

ワーカ・ジョブが開始されると、それが受け取った最後の 1 個のワークの後、ジョブの開始とシャットダウンを避けるため、追加のワークがある場合に備えて約 10 分間待機します。

このコードにより、単一クラスのコンパイル速度が上がることはなく、複数のクラスを並行してコンパイルすることにのみ焦点が当てられています。さらに、この複数 CPU コンパイルをサポートするコンパイル・プロセスの部分のみが MAC コードを INT コードにコンパイルし、これらをルーチンにアセンブルし、これらのルーチンをコンパイルし、クラス記述子を構築します。これは、コンパイルされるクラスの間に依存関係が存在しない場合にのみ、並行処理できます。コンパイラが依存関係を検出すると、これに基づいてコンパイルが自動的に停止します。したがって、クラス A と B が互いに依存していない場合、それらは同時にコンパイルできます。ただし、A が B のスーパークラスである場合、A を完全にコンパイルしてから B のコンパイルを開始する必要があり、並行処理はできません。

並行コンパイルの使用では、クラス間のすべての関連する依存関係が、クラス宣言に明示されていることを想定しています。クラスのコンパイル順序は、前のバージョンの Caché とは少し異なる場合がありますが、この順序は依然として、すべての依存関係ルールを満たしています。2 つのクラスで依存関係が指定されていない場合、それらが処理される順序は予測できません。これにより、2 つのクラスが互いに依存しているが、依存関係が指定されておらず、コンパイル順序が偶然適切に処理された場合に、問題が発生する可能性があります。その場合、クラスの間に CompileAfter または DependsOn の依存関係を追加し、それらの関係を指定します。

また、ワーカ・ジョブは、メイン・プロセスとは明らかに異なる $JOB 番号を持ちます。 これにより、コンパイル中に 1 つのスレーブ・ジョブがデータを格納し、他のスレーブ・ジョブが $JOB をインデックスとしてそのデータにアクセスしようとした場合にエラーが発生します。これは、2 つのプロセスの $JOB 番号が異なることが原因です。 この状況は、例えば、相互に対話する高度なジェネレータ・メソッドで発生することがあります。この解決策は、コンパイラ・コンテキストで定義される %ISCName ローカル変数を使用することです。これは、メイン・ジョブとすべてのワーカ・ジョブの間で一貫している名前であり、情報を共有するために使用できます。

使用されるジョブの数は、最大で 16 個であり、最近のベンチマークでは、それを超える数のジョブでは全体的なパフォーマンスは向上しないことを示しています。

InterSystems 内部アイテムの削除

このバージョンでは、メソッド・キーワード RuntimeImplementation が削除されています。これは、InterSystems による使用のみを目的としており、必要なくなりました。

また、これにより、$$$cIVARrefslot マクロも削除されています。これは、ドキュメント化されておらず、ユーザ・コードには使用しません。このマクロを使用するコードは、このバージョンではコンパイルに失敗します。

同期順序の修正

同期化設定には、オブジェクト・ファイル・イベント (挿入、更新および削除) を表すエントリが含まれています。同期化設定に、同じオブジェクトに影響を与える複数のエントリが含まれている場合、それらのエントリは元の設定と同じ発生順序で適用する必要があります。

以前のリリースでは、いくつかのエントリを異なる順序で処理するエラーが存在していました。その原因は、インポートにおける未解決の依存関係でした。未解決の依存関係により、同期化設定エントリが、後で処理されるようにスケジュールされます。この再スケジュールにより、エントリが異なる順序で適用され、データの破損が発生する可能性があります。

そのエラーは現在は修正されましたが、アプリケーションによって SyncSet エントリの処理順序について同じ想定がされていた可能性はあります。そのような場合は、特定の問題が発生しないように、アプリケーションを検証して再テストする必要があります。

%DeleteExtent でのグローバルの削除の制御

%DeleteExtent メソッドは、クラスのすべてのインスタンスの削除を試みます。すべてのインスタンスが正常に削除されると、定義されたままになっている可能性があるグローバルを削除するために %KillExtent が呼び出されます。特に複数のクラスが同じグローバルを共有している場合は、いくつかのグローバルは削除されません。

%DeleteExtent には新しいパラメータ pInitializeExtent　があり、それが true の場合は、そのクラスのすべてのインスタンスが正常に削除されたときに %KillExtent が呼び出されます。pInitializeExtent の既定値は 1 (true) です。pInitializeExtent が true ではない場合、%KillExtent は呼び出されず、%DeleteExtent が返った後、いくつかの空のグローバルが定義されたままになることがあります。そのクラスがグローバル・カウンタを使用して新しいオブジェクト ID 値を割り当てている場合は、そのグローバル・カウンタも多くの場合に定義されたままになります。

%Library.Persistent の Extent クエリ

%Library.PersistentOpens in a new tab は、%Library.PersistentOpens in a new tab を拡張するすべてのクラスによって継承されるクエリを定義します。クエリ Extent は、永続クラスのすべてのインスタンスを含む結果セットを生成するために使用されます。Extent クエリは、%Library.ExtentSQLQueryOpens in a new tab または他のクエリ・タイプとしてオーバーライドできます。 オーバーライドされたクエリは、そのクラスの各インスタンスに対応する行を返す必要があり、その最初の列は %ID である必要があります。

i%var 処理に対する変更

i%var は、インスタンス変数への直接参照を行うために <var>Get および <var>Put メソッドで使用されます。以前は、クラス・コンパイラは i%var 参照を、そのインスタンス変数が格納されている内部スロット番号に変換していました。このバージョンでは、これは、クラス・コンパイラをより動的にすることができるシステム・コードによって実行されます。 この副次的作用は、コンパイル時に i%var 名が検証されないことです。var がスーパークラス・ツリーで定義されていない場合は、このコードはコンパイルされて実行時エラーが生成されます。

SQLROWIDNAME の使用法が適用される

クラス・キーワード SQLROWIDNAME によって、ユーザは ROWID として生成される SQL 列の名前を定義できます。この SQL 列は、%Id() などのメソッド呼び出しによってのみアクセス可能なオブジェクト ID に対応しています。サブクラスのプロパティの SQLFIELDNAME をオーバーライドすることは無効です。これは、サブクラスのすべてのインスタンスは、暗黙的にそのプライマリ・スーパー・クラスのインスタンスであるというルールに違反します。同じ理由により、SQL ROWID 列名は、オーバーライドできません。

以前は、このルールは SQLROWIDNAME 値に適用されませんでした。このバージョン以降は、適用されます。それを順守しない場合は、クラスのコンパイルに失敗します。

列名として %GUID は無効である

ユーザ・クラスに %GUID という名前の既存の列がある場合、現在、これによって、クラスのコンパイル中にエラーが発生します。クラスで GUIDENABLED が true と設定されている場合、そのクラスは、%OverrideGuidAssignment() という名前のメソッド、%%GUID という名前のプロパティ、または SQLFIELDNAME が %GUID であるプロパティを実装できません。

/foldmethod 修飾子の廃止

同一のメソッドを検出し、生成されたコードに 1 つのみを残すクラス・コンパイラ /foldmethod 修飾子は廃止されました。この修飾子は、生成されたコードに何も影響を与えなくなりました。

CLASSNAME=1 を指定するプロパティを %Library.List として結合する

CLASSNAME=1 を指定するすべてのプロパティは、タイプ %Library.ListOpens in a new tab として SQL に結合されます。CLASSNAME=1 は、そのプロパティの値が Objectscript $LIST 形式の OID であることを意味します。 次のように定義されているプロパティ

Property OID As %Library.Persistent(CLASSNAME = 1) [ Required ]; 

は、以前のリリースでは、%Library.IntegerOpens in a new tab として SQL に結合しますが、このリリース以降は、%Library.ListOpens in a new tab に結合します。

セカンダリ・スーパークラスからのリレーションシップ・プロパティの継承禁止

以前のバージョンでは、セカンダリ・スーパークラスからリレーションシップを継承しようとすると、実行時にリレーションシップのサイレント障害が発生することによって無効な結果が得られました。このバージョン以降は、コンパイラがクラス・コンパイラ内でこの障害を検出し、次のようなエラーを報告するようになります。

ERROR #5572: Can not inherit relationship property 'X' in class 'Y.Z' as a secondary superclass.

この障害は、永続クラスのプライマリ・サブクラスがスーパークラスと同じエクステントを共有するのに対し、セカンダリ・サブクラスは共有しないために発生します。セカンダリ・サブクラス内の継承されたクエリは、元のクラスのエクステントを検出してクラス・データを適切に参照することができませんできした。

INT/MAC の保存によって自動的にコンパイルされない

以前のバージョンでは、INT/MAC ルーチンを保存することでコンパイルも実行できるオプションが Studio に用意されていました。今回のバージョンで、その機能は廃止されました。この動作はコンパイル・オプションの使用時に適用可能であり、機能が重複していたためです。また、変更を実行可能コードとして即座に投影されるようにしないで保存することができないことにより、テスト・システムではおそらく問題がなくても、実際の環境や共有環境で多大な損害が及ぶ可能性がありました。

どのドキュメント・タイプを保存する場合でも、単にドキュメントの現在のバージョンがサーバに再度保存されるようになりました。コンパイル操作では、常にドキュメントを保存し、その下位フォームにもドキュメントをコンパイルします。これにより、ほとんどのユーザは Studio で異なるボタンやキーストロークの組み合わせを使用しなければならなくなります。一連のドキュメントをコンパイルするには、プロジェクトおよび "ビルド" オプションを使用できます。

Java .jar ファイルのリファクタリング

今回のリリースでは、インターシステムズの Java ライブラリを 4 つにリファクタリングしました。

• cachejdbc.jar – これには Caché JDBC ドライバが含まれ、Java バインディングを使用するすべてのアプリケーションに必要です。com.intersys パッケージの jdbc、jsse、jgss、および util (今回のリリースで新たに追加) が含まれています。

• cachegateway.jar – これは Java および JDBC ゲートウェイで構成されています。cachejdbc.jar に依存しており、com.intersys.gateway および com.intersys.jdbcgate の各パッケージが含まれています。

• CacheexTRreme.jar – これは、Java eXtreme のコンポーネント (つまり、com.intersys パッケージの gloals、mds、xdo、および xep) で構成されています。

• cachedb.jar – これは、インターシステムズの Java コンポーネントの残りの部分 (Java Binding、Jalapeno、EJB (Enterprise Java Beans) など) で構成されています。com.intersys パッケージの cache、classes、codegenerator、EJB、jsp、および objects と、com.jalapeno パッケージが含まれています。

詳細は、"The Caché Java クラス・パッケージ" を参照してください。

Jalapeño の構成

Jalapeño の提供が開始されて以来、インターシステムズはパフォーマンスに影響を及ぼす Jalapeo の構成オプションを複数導入しました。ほとんどの場合に “適切な” 構成を使用することで、Jalapeño アプリケーションのパフォーマンスを (多くの場合、大幅に) 向上させることができます。ただし、既定の構成は、一般的なアプリケーションのパフォーマンスに合わせて最適化されているのではなく、むしろ Jalapeño のオリジナル・バージョンとの完全な互換性を保持することを目的としています。

このバージョンの Caché では、Jalapeño の既定の構成が変更され、アプリケーション・プログラマやエンド・ユーザに対して透過的になりました。具体的には、次の機能が利用できるようになりました。

• 特定のアプリケーションの構成をロードするための既存の機能に加えて、サイト規模の既定の Jalapeño 構成を設定するための機能が追加されました。

• サンプルの既定の構成ファイルが、一目で理解できるように改善されました。ファイルはサイト規模の既定値向けに変更することも、特定のアプリケーション向けにコピーして調整することも可能です。

• 既定の構成が、平均的なアプリケーションのパフォーマンスを向上できるように調整されました。

既定の Jalapeño 構成が、/dev/java/conf/jalapeno.properties にある Caché インストール・ディレクトリに格納されるようになりました。 このファイルは、構成可能なオプションの種類と構成方法を特定するコメントが含まれたプロパティ・ファイルです。 古いサーバ・バージョンが使用されているために、インストール時にこのファイルがない場合は、固有の既定が使用されます。ただし、その構成ファイルは、バージョン 2010.1 以降のあらゆる Caché サーバに追加することができます。 このファイルは、サーバに接続するすべてのクライアントに影響を及ぼしますが、現在のマシン上で動作しているクライアントへは影響を及ぼしません。

プロパティの Java 生成コードへの変更

新しいオブジェクトのディスパッチにより、2010.1 以降の Java ドライバでは、予測値フィールド ii_<PropertyName>、jj_<PropertyName>、または kk_<PropertyName> を使用しなくなりました。生成されたサンプルを正しく機能させるには、2010.1 以降の CacheDB.jar が必要です。

Caché eXtreme に対するクラス名の変更

この変更により、eXTreme ダイナミック・オブジェクトの Java パッケージの名前が以前の com.intersys.extreme から com.intersys.xdo (ここで “xdo” は “eXTreme ダイナミック・オブジェクト” の頭文字であり、“eXTreme Event Persistence”　の　“xep” に類似) に変更されます。 このパッケージ内のクラスの名前は以下のように変更されました。

サンプル・コード java/samples/extreme/extreme/XTDemo.java は java/samples/extreme/xdo/XDODemo.java に変更されました。

Jalapeño でのオブジェクト保存方法に対する変更

このバージョンでは、フェッチ・ポリシーが DISCARD_AFTER_FETCH であり、関連オブジェクトのリストが、親側のアプリケーションによってアクセスされなかった場合、Jalapeño は、ディープ・セーブにおいても、このリストのオブジェクトが変更されたかどうかをチェックしません。これにより、複雑なリレーションシップ・グラフと共に一連のオブジェクトをディープ・セーブするときのパフォーマンスが大幅に向上します。

ただし、次のシナリオでフェッチ・ポリシーが DISCARD_AFTER_FETCH である場合、データが失われる可能性があります。

• データベースからオブジェクト (オブジェクト A) をフェッチします。

• それ、およびそれが参照するオブジェクトに対する変更を行います。

• アプリケーション・ヒープ・メモリに参照オブジェクト (オブジェクト B) を保持します。

• ディープ・セーブを使用してオブジェクト A を保存し直し、すべての関連するオブジェクトの変更を保存します。

• オブジェクト A をフェッチし直します。

• オブジェクト B にそのメモリ内ヒープ参照を使用していくつかの変更を行います。

• ディープ・セーブを使用してオブジェクト A を保存します。

このシナリオでは、オブジェクト B に対する変更が保存されない可能性があります。これらの状況では、アプリケーションで、記録しておくためにオブジェクトを保存した後で、アプリケーション・コンテキストでオブジェクトの暗黙的な変更が想定されている場合、フェッチ・ポリシー DISCARD_AFTER_FETCH を使用しないでください。ポリシー REFETCH_AFTER_FETCH を使用してください。

Jalapeño での Java マッピングに対する変更

このバージョンでは、Java 整数のマッピングは、Caché データ型クラス %IntegerOpens in a new tab から %EnumStringOpens in a new tab に変更されました。これにより、ODBC で使用される論理値の処理が、より直感的になります。

ActiveX および C バインディングに対するデータ型コレクション・プロパティでの大部分の特定のタイプの使用

このリリースの前は、コレクション・プロパティは、ダイナミック C++ バインディングの文字列のコレクションとして投影されました。例えば、プロパティ

property sysListColn as list of %List;

は、文字列のコレクションとして投影されました。これは、コレクションのいずれかの要素が不適切に %String に変換されていた場合に、%List 全体を破損する可能性があるという良くない結果を招きます。

現在は、コレクション・プロパティのタイプに対して返されるダイナミック・クラス定義は、適切なコレクション要素タイプを反映します。例えば、現在は、sysListColn と関連付けられたダイナミック・クラス定義のメソッド GetAt() のメタ情報は、戻り値のタイプ ID が D_LIST_ID であることを示しています。

C++ クエリで使用される 10 進数値の値の保持

以前のバージョンでは、d_query は d_decimal を ODBC に対して SQL_C_DOUBLE として表していました。現在は SQL_C_CHAR を使用します。文字列変換では、数値の正確な値が保持されます。

ID の後に続く括弧で囲まれたリテラルの置換

SQL パーサにおける変更のため、まれに、定数の置換を防止するために手動で括弧で囲んだ定数は、同様の効果を得るために 2 つのペアの括弧によって囲む必要がある場合があります。つまり、以下のようなインスタンスの場合

...
WHERE f4 = ('Hello')
...

以下のように変更する必要があります。

...
WHERE f4 = (('Hello'))
...

下位互換性のために、特定のコンテキストでは、1 つのペアの括弧が、リテラルの置換の防止策として引き続き機能します。次に例を示します。

...
SELECT TOP (5) f6
...

この変更の前は、括弧が ID "IN" の後に続く場合は、括弧で囲まれたリテラルに対してもリテラルの置換が実行されました。そのような場合に、リテラルの置換を防止するには、それを 2つのペアの括弧で囲みました。このロジックは変更され、TOP、SELECT、LIKE、WHERE、ON、AND、OR、NOT、BETWEEN、%STARTSWITH、CASE、WHEN、および ELSE 以外のすべての識別子の後に続く括弧で囲まれたリテラルが置換されるようになりました。

ダイナミック SQL がファイル内の文の使用をサポートする

ダイナミック SQL シェルでは、SQL 文のファイルからのロードとファイルへの保存を行うための LOAD および SAVE コマンドがサポートされるようになりました。SAVE は従来、現在作成済みの文を文のグローバルに保存するために使用されていましたが、再定義されました。今後、文のグローバルに保存する場合は、SAVEGLOBAL (または省略形の SG) を使用する必要があります。

LOAD を使用すると、指定したファイルのコンテンツが現在の文のバッファにロードされ、文が作成されます。EXECUTEMODE が IMMEDIATE の場合には、文が正常に作成されると同時に実行されます。

SAVE を使用すると、現在作成済みの文がファイルに保存されます。指定したファイルが既に存在する場合は、ファイルの上書きを求めるプロンプトが表示されます。上書きを選択しないと、エラーが報告され、その文は保存されません。

ダイナミック SQL と CALL 文

バージョン 2010.2 より前の埋め込み SQL では、ターゲットが関数でない場合の CALL 文はサポートされていませんでした。 関数は埋め込み SQL を使用して呼び出すことができました。今回のリリース以降、関数に対して CALL を使用するアプリケーションには変更が必要になります。呼び出されるプロシージャによって結果セットが返される場合は、アプリケーションで新しい %SQL.StatementOpens in a new tab クラスを使用する必要があります。呼び出されるルーチンが関数であり、以前のバージョンでサポートされていた場合は、アプリケーションで “SELECT <SQL Routine> <arguments>” を代わりに使用してください。

Sybase および MS SQL Server 用インポート・ユーティリティの再実装

Sybase および MS SQL Server 用の SQL 文のインポートが再実装されました。今後、Sybase および MS SQLServer 文は、ダイナミック SQL を使用して処理されます。また、文の作成結果および作成された文の実行結果は、ファイルにログ記録されると共に、オプションで現在のデバイスにエコーされます。インタフェースに変更はありませんが、ダイアログが若干変更されました。また、ログ・ファイルの形式が異なり、パーサには TSQL パーサが使用されます。これによって、より多くの構文が処理されるだけでなく、報告されるエラーも異なります。正常に処理された文に関しては、最終的な結果は同じになるはずです。

定義済みのプロシージャに制限された CALL

今回のリリースでは、クラス・メソッド/クエリが SqlProc として指定されていなくても、SQL CALL 文によってそのメソッド/クエリがストアド・プロシージャとして呼び出される可能性があるループホールが解消されました。そのため、SQL プロシージャとして定義されていないクラス・メソッド/クエリが SQL CALL 文から呼び出された場合に、クラス定義の変更が必要となることがあります。その場合、クラス定義を変更して SQL プロシージャとして宣言する必要があります。

UNION を使用するビューに対してクエリを処理するための変更

今回のリリースでは、クエリの一部として UNION を使用するビューに対するクエリの問題が修正されました。以下に例を示します。

SELECT 1 UNION SELECT 'one'

返されるクエリ・メタデータでは、クエリの 1 列目の型が INTEGER ではなく VARCHAR として報告されるようになります。

行選択での %vid の使用

TOP の代わりとして、このバージョンではクエリで返される行のセットを制限するための新しい方法が導入されました。今回のリリースでは、%vid がビューおよび FROM 節のサブクエリに拡張されています。これは、順番に割り当てられた行番号を表します。したがって、任意のクエリから行 5 ～ 10 を取得するには、次のように指定します。

SELECT *, %vid FROM (SELECT ....) v WHERE %vid BETWEEN 5 AND 10

SQL 文のプロパティの変更

%SQL.StatementOpens in a new tab の %Language プロパティの名前が、%Dialect になりました。また、SQL シェルの LANGUAGE オプションの名前が、DIALECT になりました。

Informix の移行 — SUBSTR 関数

以前のバージョンでは、SUBSTR 関数が SQL コンテキスト内で検出されると、3 番目の引数が末尾位置として誤って渡されました。このバージョンでは、SQL SUBSTR 関数は、長さを 3 番目の引数として正しく受け取ります。

TSQL でサポートされていない関数

TSQL システム関数、IS_SRVROLEMEMBER、IS_MEMBER、および ServerProperty は、Caché TSQL によって実装されません。今後、これらの関数への参照は、コンパイラ・エラーとして報告されます。

TRUNCATE の照合の追加

Caché SQL では、TRUNCATE という新しい照合がサポートされるようになりました。 TRUNCATE は EXACT と同じですが、アプリケーションで値を切り捨てる位置を指定できます。 これは、アプリケーションでインデックスの作成が必要な EXACT データがあり、そのデータが Caché の添え字の最大長を超えている場合に便利です。

長さの引数をサポートする他の照合と同様に、TRUNCATE(len) では EXACT 値が “len” で指定された文字数に切り捨てられます。 TRUNCATE に長さが指定されていない場合、この照合の動作は EXACT と同じになります。 これは技術的にはサポートされていますが、長さを定義する場合にのみ TRUNCATE を使用し、長さを定義しない場合は EXACT を使用することによって、定義やコードの保守がより簡単になります。

Caché でサポートされている他の照合と同様に、%TRUNCATE も SQL文で単項関数として使用できます。 以下はその例です。

Set MyStringFirst100 = $extract(MyString, 1 ,100)
&SQL (SELECT ALongString 
      INTO :data
      FROM MyTable 
      WHERE %TRUNCATE(ALongString,100) = :InputValue)

TRUNCATE を %CacheSQLStorage マップ定義のマップ・スクリプト式で使用する場合、サブスクリプトの定義には $$TRUNCATE を使用します。 例えば、マップ・サブスクリプト式は次のように指定できます。

$$TRUNCATE({MyLongStringField}, 100)

$SYSTEM.SQL.TOCHAR および $SYSTEM.SQL.TO_CHAR に対する変更

$SYSTEM.SQL.TOCHAR(<null>) および $SYSTEM.SQL.TO_CHAR(<null_value>) では、数値から文字への変換で 0 の代わりに NULL が返されるようになりました。

選択性のヒントを指定するための %inlist() の 2 番目の引数 (オプション) のサポート

%inlist 演算子は、2 番目の引数 (オプション) を持つ関数としても使用できるようになりました。これは、クエリに含まれる要素の数の桁を指定するために使用します。したがって、少数の異なるクエリ・キャッシュを使用して、さまざまな場合に対して異なる計画が得られます。以下はその例です。

• 小規模リスト – %inlist <list> SIZE ((10))

• 中規模リスト – %inlist <list> SIZE ((100))

• 大規模リスト – %inlist <list> SIZE ((1000))

• 巨大リスト – %inlist <list> SIZE ((10000))

2 番目の引数は、コンパイル時に定数である必要があります。つまり、埋め込み SQL 以外のクライアントからの場合、上記の例と同様に括弧を必ず使用してください。

TO_CHAR の処理における変更

このバージョンの Caché では、論理 %TimeOpens in a new tab 値から文字列値への変換をサポートするために TO_CHAR が機能拡張されました。 最初に変換される式の値が数値で、形式に次のような時刻関連の形式コードのみが含まれているとします。

• HH – 時間 (1 ～ 12)

  HH12 – 時間 (1 ～ 12)

  HH24 – 時間 (0 ～ 23)

  MI – 分 (0 ～ 59)

  SS – 秒 (0 ～ 59)

  SSSSS – 午前 0 時 00 分からの秒数 (0 ～ 86388)

  AM – 午前

  PM – 午後

この式は、論理 %DateOpens in a new tab 値ではなく、論理 %TimeOpens in a new tab 値として処理されます。以下は選択の例です。

SELECT TO_CHAR($piece($horolog, ',' ,2), 'HH12:MI:SS PM') AS THE_TIME

この場合、THE-TIME に 11:43:26 AM のような形式の値が含まれることになります。

SQL プリプロセッサでのマクロや関数の評価

今回のリリースから、埋め込み SQL 文としてコンパイルされた場合や、ダイナミック文として作成された場合の、DDL CREATE PROCEDURE、CREATE FUNCTION、CREATE METHOD、CREATE QUERY、および CREATE TRIGGER の各文の動作が変更されています。この変更では完全な下位互換性は確保されていないため、特に ObjectScript タイプのコード本文を CREATE 文で使用する場合には、アプリケーションに変更が必要となることがあります。

マクロ・プリプロセッサでは、埋め込み SQL 文の処理前に # コマンド、## 関数、および $$$ マクロの参照が評価されます。次の文について考えてみましょう。

&sql(CREATE PROCEDURE SquareIt(in value INTEGER) RETURNS INTEGER 
                      LANGUAGE COS { 
                          #define Square(%val) %val*%val
                          QUIT $$$Square(value) 
                          }
    ) 

この変更以前は、CREATE PROCEDURE 文がコンパイルされて次のようなメソッド宣言になる場合に、#define および $$$Square マクロ参照が拡張および処理されていました。

ClassMethod SquareIt(value As %Library.Integer(MAXVAL=2147483647,MINVAL=-2147483648))
            As %Library.Integer(MAXVAL=2147483647,MINVAL=-2147483648)
            [ SqlName = SquareIt, SqlProc ]
{ 
    QUIT value*value 
} 

この変更で、この処理および拡張はプロシージャ・メソッドの定義に追加され、メソッドのコンパイル時に処理と拡張が行われるようになります。

ClassMethod SquareIt(value As %Library.Integer(MAXVAL=2147483647,MINVAL=-2147483648))
            As %Library.Integer(MAXVAL=2147483647,MINVAL=-2147483648)
            [ SqlName = SquareIt, SqlProc ] 
{ 
    #define Square(%val) %val*%val 
        QUIT $$$Square(value) 
} 

CREATE PROCEDURE 文のコンパイル中に発生するマクロ拡張の以前の動作に依存するコードは、変更する必要があります。別の方法として、%SQL.文を使用して、CREATE PROCEDURE 文を動的に作成し実行します。

最後に、以前のリリースでは、ObjectScript プログラム・コードは、{ code } のように中括弧で囲みます。情報を含める必要がある場合、#Include プリプロセッサ・コマンドは次の例に示すように、コロンで始まり、最初の列に表示されるようにしてください。

CREATE PROCEDURE SP123() 
  LANGUAGE OBJECTSCRIPT { 
:#Include %occConstant 
}

今回のリリース以降、先頭のコロン (:) は必要なくなりましたが、付けた場合でもエラーが発生することなく受け入れられます。

日付/タイムスタンプの比較と SQL カテゴリに対する修正

データ型クラスの %Library.DateOpens in a new tab、%Library.TimeStampOpens in a new tab、%Library.FilemanDateOpens in a new tab、%Library.FilemanTimeStampOpens in a new tab、および %MV.DateOpens in a new tab は、SqlCategory に関して次のように処理されるようになりました。

1. %Library.DateOpens in a new tab クラスおよび +$HOROLOG の論理値を持つユーザ定義のデータ型クラスには、SqlCategory として DATE を使用する必要があります。

2. %Library.FilemanDateOpens in a new tab クラスまたは CYYMMDD の論理日付値を持つユーザ定義のデータ型クラスには、SqlCategory として FMDATE を使用する必要があります。

3. %MV.DateOpens in a new tab クラスまたは $HOROLOG-46385 の論理日付値を持つユーザ定義のデータ型クラスには、SqlCategory として MVDATE を使用する必要があります。

4. %Library.FilemanTimeStampOpens in a new tab クラスまたは CYYMMDD.HHMMSS の論理日付値を持つユーザ定義のデータ型クラスには、SqlCategory として FMTIMESTAMP を使用する必要があります。

5. 上記の論理値のいずれにも当てはまらないユーザ定義の日付データ型には、データ型の SqlCategory を DATE として定義し、データ型クラスに LogicalToDate メソッドを指定して、ユーザ定義の論理日付値を %Library.DateOpens in a new tab 論理値に変換する必要があります。

6. 上記の論理値のいずれにも当てはまらないユーザ定義のタイムスタンプ・データ型には、データ型の SqlCategory を TIMESTAMP として定義し、データ型クラスに LogicalToTimeStamp メソッドを指定して、ユーザ定義の論理タイムスタンプ値を %Library.TimeStampOpens in a new tab 論理値に変換する必要があります。

7. 最後に、

   • %Library.FilemanDate の SqlCategory は、FMDATE になりました。

   • %Library.FilemanTimeStamp の SqlCategory は、FMTIMESTAMP になりました。

   • %MV.Date の SqlCategory は、MVDATE になりました。

このバージョンでは、FMTIMESTAMP カテゴリの値と DATE カテゴリの値との比較の結果も変更されています。 Caché では、DATE と比較する前に FMTIMESTAMP 値から時間を削除することはなくなりました。 この動作は、TIMESTAMP と DATE の値の比較、および TIMESTAMP と MVDATE の値の比較に対する動作と同じになりました。 これは、他の SQL ベンダによる TIMESTAMPS と DATES の比較方法とも互換性があります。 つまり、FMTIMESTAMP 320110202.12 と DATE 62124 の比較は、SQL = 演算子との比較時と等しくなくなります。 アプリケーションでは、FMTIMESTAMP を DATE または FMDATE 値に変換して値の日付部分のみを比較する必要があります。

CASE 式のデータ型

CASE 式を使用する際に、考えられる返り値のいずれかが LONGVARBINARY 型である場合、CASE の返り値は LONGVARBINARY 型となります。それ以外では、考えられる返り値のいずれかが LONGVARCHAR 型である場合、CASE 関数の返り値は LONGVARCHAR 型となります。その後、値のデータ型は、VARBINARY、VARCHAR、TIMESTAMP、DOUBLE、NUMERIC、BIGINT、INTEGER、DATE、TIME、SMALLINT、TINYINT、BIT の間から初めて適用可能となります。

CSP アプリケーションの変更時のエラー処理

イベント・クラスは、CSP アプリケーションにアタッチできます。特に、セッションがアプリケーション間を移動する際にコールバックが実行されます。設計上の意図に従い、エラー・コードが返された場合には、フローがエラー・ページにリダイレクトされます。

以前のリリースでは、このエラー・コードは “部分的に” 無視されました。エラー・コードが返されたら、ユーザはエラー・ページにリダイレクトされました。ただし、アプリケーションの変更が完了し、ユーザが実際にターゲット・アプリケーションにログインしている場合は、再ロード・ボタンを押すとターゲット・ページが表示されました。今後は、エラー・コードでアプリケーションの変更が中止されます。同じエラー・ページが表示されますが、再ロード・ボタンを押すとエラー・ページが再表示されます。

CSP アプリケーションを認証するためのスティッキー・ログインとログイン・トークン

CSP ログインは、“スティッキー” になりました。以前に起動したアプリケーションを再起動すると、そのアプリケーションは終了時と同じユーザになります(以前は、セッションを共有すると、再起動時のユーザは他のアプリケーションへのアクセス状況に応じて異なりました)。X としてログインすると、ログイン・トークンが "最も最近ログインしたユーザ" Cookie に含まれてブラウザに送信されます。アプリケーションを初めて起動すると、ログイン・トークンがアプリケーションに対して有効である場合には、CSP サーバはその Cookie を使用してユーザのログイン処理を試みます。

セッション内のすべてのアプリケーションが連動するようになりました。アプリケーション内の新しいユーザにログインすると、すべてのアプリケーションがそのユーザに移ります。 セッションをログアウトすると、セッション内のすべてのアプリケーションからログアウトします。

CSP アプリケーションのブラウザ単位のグループ化を許可

Caché には、セッション単位とブラウザ単位の 2 種類の認証グループがあります。 グループ内の CSP アプリケーションは、可能な限りそれぞれの認証が同期している状態を維持しようとします。すべてのアプリケーションは、1 つの認証グループに含まれます。アプリケーションの既定の認証グループはセッション単位です(そのため、セッション内のアプリケーションだけで単一エンティティの認証グループが形成されます)。明示的なグループ化は、暗黙的なグループ化よりも優先されます。つまり、ブラウザ単位でグループ化されているアプリケーションが他のアプリケーションを含むセッションに強制的に追加される場合、そのアプリケーションはセッション単位ではなくブラウザ単位で認証を他のアプリケーションと共有します。

正確な Cookie パスの一致に基づくセッション共有

以前のバージョンでは、アプリケーションの起動時に最初のアプリケーションの Session-Path-Cookie が以前のアプリケーションの接頭語であった場合、2 つのアプリケーションは同じセッションに含まれました。しかし、このルールでは不整合が生じていました。アプリケーションが反対の順番で起動された場合、これらのアプリケーションは同じセッションではなく異なるセッションに含まれたためです。

今後は、アプリケーションの Session-Path-Cookie が正確に一致した場合、アプリケーションが同じ CSP セッションを共有する (同じ CSP セッションで実行される) ようにすることができます。セッションを共有するアプリケーションは、セッション・オブジェクト内のデータを共有することができ、可能な限りそれぞれの認証が同期している (同じユーザへのログインが保持され、ユニットとしてログアウトされる) 状態を維持しようとします。

セッション・イベントとセキュリティ・コンテキストの管理

今回のリリースでは、セッション・イベント・クラスとそのセキュリティ・コンテキストに 2 つの重要な変更が加えられました。1 つ目は、イベントの発生時に CSP セッションで複数のクラスが通知されるようにすることが可能になりました。つまり、次のような文があるとします。

SET %session.EventClass = "User.MyClass"

この場合、コールバックするクラスのリストに User.MyClass が追加されます。また、次のような文があるとします。

SET %session.EventClass = "User.MyClass1", %session.EventClass = "User.MyClass2"

この場合、両方のクラスがリストに追加されます。この動作はどちらも容易に説明できます。また、これによって、アプリケーションが既存のイベント・クラスを誤って削除して、クリーンアップ・コードを実行できないようにし、その結果、リソース・リークが発生する可能性が生じないことが保証されます。

2 つ目は、同じセッション内での CSP アプリケーション間の移動時に、新しいアプリケーションのイベント・クラスが自動的にリストに追加されるようになりました。以前のリリースでは、新しい CSP アプリケーションのイベント・クラスが無視され、そのアプリケーションに関連付けられたネームスペースで作成された一時データのクリーンアップの妨げとなっていました。

ACCEPT_LANGUAGE の * に対する CSP 一致言語の固定

CGI 変数の HTTP_ACCEPT_LANGUAGE の値が “*” (あらゆる言語を意味します) であり、品質評価が特定の言語と同じ場合は、その特定の言語を使用します。 これにより、HTTP 1.1 規則が実装されます。つまり、Accept-Language フィールドによって言語タグに割り当てられる言語品質要素は、フィールドにある最長言語でその言語タグに一致するものの品質値です。

Cookie Timeout の名前変更

さまざまなセッションやプロセスなどの個別のタイムアウトと、ブラウザによって制御されている Cookie の有効期限を区別するために、今回のリリースでは “cookie timeout” から “cookie expire time” に名前が変更されました。

%XML.DataSet でのクラス/プロパティのメタデータの使用 (使用可能な場合)

以前のバージョンでは、%XML.DataSetOpens in a new tab は実行中のクエリから SQL メタデータのみ使用しました。 特にこれは、%xsd パッケージからの基本データ型の xsdtype のみがサポートされることを意味し、プロパティ・パラメータ (プロパティの VALUELIST など) や、XSDToLogical および LogicalToXSD のオーバーライドはサポートされていませんでした。 今後、%XML.DataSetOpens in a new tab は、使用可能な場合に列のクラス名やプロパティ名のメタデータを調べます (列が式である場合など、常に使用可能であるとは限りません)。この変更により、SQL ベースのデータを使用するだけのアプリケーションは影響を受けます。

埋め込みのスペースを使用する列名

今回のバージョン以降、%XML.DataSetOpens in a new tab は列名に含まれる埋め込みのスペースをアンダースコアに変換します。

Web アドオンの宣言が必要

アプリケーションが Web アドオン・ライセンスの条件のもとで実行できる匿名の Web アプリケーションとして識別される必要がある場合、アプリケーションはそのように識別されるように $SYSTEM.License.PublicWebAppUser() を呼び出す必要があります。

SOAP フォルトの処理

このバージョンの Caché では、WS-I Basic Profile で定義されているように、SOAP 1.1 フォルトがクライアント・エラーの場合は HTTP 状態コード 400、サーバ・エラーの場合は 500 で返されます。 SOAP 1.2 フォルトは、既にこの状態コード 400 および 500 の使用法に従っていました。さらに、Initialize メソッドによって生成されるすべての %StatusOpens in a new tab ベースのフォルトに対して、OnInternalFault が SOAP によって呼び出されます OnInternalFault は、コードの別の場所で生成される %StatusOpens in a new tab ベースのフォルトに対して既に呼び出されていました。

クライアントでフォルトに対して状態コード 200 を必要とする場合、このコードは機能しなくなったため、クライアント・アプリケーションの変更が必要になります。

ウィザードでの SOAP ヘッダ生成の廃止

SOAPHEADERS パラメータは、SOAP ウィザードによって生成されなくなりました。 代わりに、パラメータの XData ブロックを使用して、メソッド・レベルで必要なヘッダを WSDL に基づき指定します。

Web サービスや Web クライアントに関する追加のヘッダ情報は、Web サービス・クラスや Webクライアント・クラスの XData ブロックに追加されます。 XData ブロックには、ルート要素として configurationOpens in a new tab ネームスペースにパラメータ要素が含まれます。

メソッド名の最大長

今回のリリースでは、SOAP によってメソッド名の長さが 180 文字に設定されます。一部のメソッドは、トランケーションが必要なくなったため、SOAP ウィザードで再作成されたときに違う名前になる可能性があります。

ストリームを閉じない

このリリース以降、SOAP の Web サービスおよび Web クライアントによって使用されるファイル・ストリームを実装するファイルは、それらを使用するストリームが終了するまで閉じられません。

行継続処理の変更

BASIC および MV BASIC 行継続文字で、複数の行にまたがるソース行を実現できます。 行継続文字を行の最後の文字として配置することで、その文を次の行に続けることが可能です。 BASIC 行継続文字はアンダースコア (_) です。一方、MVBASIC には、エミュレーション・オプションに応じて、垂直バー (|) または円記号 (\) のいずれかを行継続文字として使用できます。

以前のバージョンの BASIC および MVBASIC では、場合によって行継続文字を行の最後の文字以外の場所に配置することができましたが、 行継続文字に目的の違う別の使用法があると問題が生じる可能性がありました。そのため、今回のリリース以降は、継続文字を必ず行の最後の文字として使用する必要があります。

XA のすべてのサポートの廃止

この変更によって、インターシステムズの JDBC ドライバから一部の試験的な XA コードが削除されました。Caché では、XA プロトコルはサポートされておらず、JDBC ドライバもサポートされていませんでした。ただし、これは何度も真剣に検討されてきたため、将来的に JDBC で完全にサポートできるかどうかをテストするための試験的なコードが追加されていました。この機能はドキュメントでサポート対象外として示されていましたが、インターシステムズは全体的な Java のクリーンアップの一環として、この使用されていないコードの削除を決定しました。

カタログ・クエリに対する変更

ODBC カタログ・クエリ SQLTables と JDBC カタログ・クエリ getTables の TABLE_TYPE 引数が強化され、常にサポートされてきた 'TABLE' および 'VIEW' タイプに加えて、次のタイプが新たにサポートされるようになりました。

• SYSTEM TABLE – System > 0 の設定を持つクラスから投影されるテーブル

• SYSTEM VIEW – System > 0 の設定を持つクラスから投影されるビュー

• GLOBAL TEMPORARY – 次のようなクラス・パラメータが含まれているクラスから投影されるテーブル

  Parameter SQLTABLETYPE = "GLOBAL TEMPORARY";
  

以前のバージョンでは、アプリケーションで空の TABLE_TYPE 引数を持つ SQLTables または getTables が呼び出されると、TABLE および VIEW タイプのみが返されました。 今後は、カタログに存在するすべてのタイプが返されるようになります。 アプリケーションで TABLE および VIEW タイプのみが返されるようにする場合は、TABLE_TYPE 引数に 'TABLE' および 'VIEW' のみが渡されるように変更する必要があります。

MVFILENAME クラス・パラメータ

MVFILENAME の存在により、VOC におけるコピーまたはインポートされたクラスとファイル参照間に生じていた可能性のある不整合の問題が解決されます。MVFILENAME の使用により、%MV.AdaptorOpens in a new tab を拡張するクラス内のストレージ定義が、MV ファイルの定義に厳密に従うようになりました。MVFILENAME を使用することを強くお勧めします。

D3 エミュレーションのデバッガの変更

D3 エミュレーションを使用する MultiValue アカウントでスタジオ・デバッガを使用すると、デバッガは、大文字と小文字が混在した変数名または小文字の変数名が見つからない場合に、大文字の名前を検索します。 これは、すべての変数名を大文字に変換する D3 の既定の動作をデバッグ・ルーチンで使用する場合に便利です。しかし、次の場合は、混乱を招く可能性があります。

$OPTIONS -NO.CASE

この場合、ルーチンの既定値が無効になり、名前の大文字と小文字のみが異なる 2 つの変数名が使用されます。大文字と小文字を区別してコンパイルされる D3 ルーチンで、大文字と小文字のみが異なる複数の変数名を使用する場合、デバッガで予期しない値が示される可能性があります。

この変更は、表示変数にのみ適用されます。 値を変更するには、正しい大文字の名前を使用する必要があります。

SUM 動詞が変更され、エラー・メッセージ経由で情報を返すようになった

このバージョンでは、SUM 動詞は、エラー・メッセージの形式で結果を生成するようになりました。以前、結果は RETURNING 節経由で表示されていました。

割り当てのないエントリを持つ動的配列に対する動作の変更

割り当てのない配列ノードに対する NULL エントリを末尾に持つ MATBUILD/MATWRITE 動的配列を埋め込む従来の動作は、サポートされなくなりました。 この動作を提供する従来の MultiValue システムは存在しないため、この動作に依存する既存のアプリケーションはないはずです。

以前のリリースでは、割り当てのないノードは空の文字列として処理されるため、上位の配列添え字が定義されていない場合、結果の動的配列には末尾に空のエントリが多数含まれる可能性がありました。今回のリリースから、割り当てのないノードを持つ配列に対して、MATBUILD および MATWRITE の動作が変更されました。 今後、動作はエミュレーション・オプションに依存します。このオプションは、次のように既存の従来のプラットフォームの動作に適合するように設定されます。

• Cache、Universe、および Unidata エミュレーション

  空の文字列が割り当てのないノードに使用され、動的配列の最上位の添え字が割り当てられていない場合は、配列が切り捨てられます。

• jBase、Reality、および D3 エミュレーション

  割り当てのない配列ノードが検出された場合は、<UNDEFINED> エラーがスローされます。

エミュレーション・タイプに基づく既定の動作は、コンパイル・オプションによってオーバーライドされる可能性があります。

$OPTIONS MATBUILD.UNASSIGNED.ERROR

この場合は、エラーがスローされます。一方、

$OPTIONS -MATBUILD.UNASSIGNED.ERROR

この場合は、空の文字列が使用され、末尾の割り当てのないノードは切り捨てられます。

時間制限付きの INPUT および AUTOLOGOUT の動作の変更

以前のリリースで、AUTOLOGOUT は予測不可能であることがわかりました。今回のリリースでは、AUTOLOGOUT 文および時間制限付きの INPUT 文で一貫性が確保されています。アプリケーションにタイムアウトした INPUT コマンドが含まれている場合の動作が若干変更されました。例えば、次のようにタイムアウトが 30 秒であったとします。

INPUT var FOR 300 ELSE ...

以前のリリースでは、30 秒が INPUT 文全体に適用されました。今回のリリース以降、INPUT 文の途中でキーが押されるたびにタイムアウトがリセットされ、新たに 30 秒がカウントされます。 同様の動作の変更が AUTOLOGOUT にも適用されました。キーストロークごとに AUTOLOGOUT のタイムアウトがリセットされます。

jBase とディメンジョンが指定されていない配列

今回のリリースでは、ディメンジョンが指定されていない配列の参照は、JBASE エミュレーションでコンパイル・エラーとなります。以前は、暗黙的な FMT 処理として扱われていました。

jBase CommandInit と CommandNext の変更

以前のリリースでは、ルーチンの CommandInit および CommandNext (jBASE の最近のリリースでは JBASECommandInit および JBASECommandNext) を呼び出すために、Caché インストールで提供されている samples ディレクトリに F ポインタを作成して、CommandInit と CommandNext をコンパイルしてカタログに入れる必要がありました。

今回のリリース以降、ルーチンの CommandInit および CommandNext (また、新しい等価機能である JBASECommandInit および JBASECommandNext) は、Caché によって既定で提供されます。そのため、使用前に顧客がコンパイルを行う必要はありません。これら 2 つのルーチンのソースは必要なくなったので、今後、Caché のリリースによって提供されることはありません。

CommandNext から返される値は、以前と同様に CommandInclude という名前のファイルで定義されるため、顧客は返り値をデコードする際に今後もこのファイルを使用する必要がある場合があります。このソースは、Caché リリースに引き続き含まれ、以前と同じ次の場所に格納されます。

<install_directory>/dev/mv/samples/CommandInclude

CommandNext ルーチンの呼び出しでは、3 番目のパラメータがタイムアウト値です。Caché で、次のタイムアウト値がサポートされるようになりました。

• timeout < 0: ルーチンは即座に値を返します

• timeout = 0: timeout = 1 と同じです

• timeout > 0: Caché によってタイムアウト値が返されるまでの待機時間です (10 分の 1 秒単位)

jBase CHAIN の処理

MVBASIC CHAIN 文は、jBASE エミュレーション中に正しく処理されない場合がありました。 jBASE エミュレーションでの CHAIN は、既定のリスト (リスト 0) がローカルであるか変更されている場合、そのリストを渡してはいけません。 しかし、MVBASIC が EXECUTE 文によって開始された場合、CHAIN は既定のリストを常に渡すようになっていました。 今後、jBASE エミュレーションでコンパイルされるプログラムに対して、既定のリストを渡す動作が常に無効になります。

ブーリアン演算子の評価順序

MVBASIC のブーリアン AND 演算子 (AND、“&”) とブーリアン OR 演算子 (OR、“!”) の評価順序が、MVBASIC の仕様と一致するように変更されました。 以前は、MVBASIC 論理積演算子 (AND、“&”) は、論理和演算子 (OR、“!”) よりも優先されました。 括弧がない場合、AND 演算子は OR 演算子より先に評価されるようになっていました。 今後は、AND 演算子と OR 演算子の優先順位が等しくなり、括弧がない場合は左から右の順序で評価されます。

0 による除算の処理

このバージョン以降、MVBASIC DIVS() および MODS() 配列関数は、0 による除算エラーが発生したときに、<DIVIDE> エラーを通知するようになりました。 これにより、DIVS() 関数の実行が終了し、トラップ・ハンドラの検索が開始されます。 これまでは、DIVS() 配列操作中に 0 による除算が行われた場合、オペレータのコンソール・ログにメッセージが送信され、配列コンポーネントに使用されていた 0 がエラーになり、残りの要素を使って配列の除算が続行されていました。

MVENABLED クラスのリスト・コレクションを空にできない

MVENABLED クラスのリスト・コレクションにおけるインデックスには、常に少なくとも 1 つのエントリが含まれます。このコレクションが空の場合、インデックスには、インデックス付き要素値 NULL とキー値 1 が挿入されます。

DEFFUN CALLING の構文変更

DEFFUN 文の CALLING 節の構文が変更されました。 CALLING キーワードに続けて、識別子、または引用符で囲まれた文字列リテラルを指定することができるようになりました。 引用符で囲まれた文字列リテラルを使用する場合、この文字列リテラルの先頭に “*” 文字を使用することもできます。先頭文字が “*:” である場合、

• Unidata エミュレーションでは、名前が “*” で始まる場合、先頭の * が削除され、この名前はグローバル名として検索されます。 該当するグローバル名が見つからない場合、エラーとなります。

• Unidata 以外のエミュレーションでは、関数名の先頭に “*” 文字を使用することもできますが、このようなエミュレーションでは、先頭の “*” により、名前の検索規則が変更されることはありません。

PRINT ON <Channel> はエミュレーション固有に

このリリースでは、文の使用における MultiValue エミュレーションの差が追加されます

PRINT ON channel {EXPRESSION}

これ以前のリリースでは、使用しているのが PRINTER ON でも、PRINTER OFF でも関係なく、出力は必ずスプーラの印刷ジョブに送られていました。今回のリリースでは、このアクションはエミュレーションに依存するようになります。Reality、jBASE、D3 などのエミュレーションでは、アプリケーションで PRINTER ON 文が実行されていない場合、出力は画面に表示されます。その他のエミュレーションでは、動作は変わらず、スプールされたジョブに出力されます。

SPOOLER(2) 関数の返り値の変更

これ以前のリリースでは、MVBASIC の SPOOLER(2) 関数呼び出しにおいて、互換性の理由で同一の 3 フィールドが返されていました。今回のリリース以降、重複フィールドの 1 つ (フィールド 15 または MultiValue 15) は、ロック・ダウンされ、セキュリティが有効になっているシステムで、ユーザが最初に Caché に接続するときに使用する Caché ユーザ名となります。次の値/フィールドは関連する情報を共有しているので、この対象となります。

• 3 – ユーザ名。OS ログイン名 = Fred

• 14 – ユーザ名。OS ログイン名、3 と同じ = Fred

• 15 – セキュリティが有効で、ロック・ダウンされているシステムでの Caché ユーザ名、または “UnknownUser”

• 17 – MV アカウント名。= USER

PROC P コマンドでデータ・スタックの Universe/Unidata 動作をサポート

このバージョンから、PROC P コマンドはエミュレーション・フラグ STACK.GLOBAL を遵守するようになります。したがって、このフラグが設定されている場合、PROC は P コマンドを実行するときにデータ・スタックをクリアせず、セカンダリ出力バッファを追加するようになります。

SSELECT の結果の順序の変更

これ以前のリリースでは、MVBasic SSELECT 文の順序と、SELECT 文の順序は同じ、つまり Caché の既定の照合順序でした。Caché の既定では、最初に空の文字列が来て、次にキャノニック形式の数値、最後に残りの文字列の順に並べられます。

このバージョン以降、ファイルから作成されたリスト、またはその他の選択されたリストは、通常の文字列照合順序で並べられます。 数字文字列を数字の順序に並べる必要がある場合、プログラマは SSELECT ではなく SELECT を使用する必要があります。SSELECT 文への入力が、重複した値を含むリスト変数である場合、ソート処理の一環として、重複した値は 1 つの値で置き換えられます。したがって、リスト変数を SSELECT すると、要素数のより少ない、新しいリスト変数が生成される可能性があります。

Unidata に対する MATBUILD および MATWRITE の動作の変更

このバージョン以降、Unidata エミュレーションにおける MATBUILD および MATWRITE による末尾にくる空の値の処理が異なります。 MATWRITE はこのような値を切り捨てますが、MATBUILD は切り捨てません。

動的なベクトル計算の変更

以前のリリースでは、値 0 による除算の実行が求められた場合、

• DIV() および MOD() 関数、および / 除算演算子は <DIVIDE> エラーを発行していましたが、

• DIVS() および MODS() 関数 (動的配列ベクトル計算) は値 0 を返していました。

このリリース以降、これらの演算すべてで同じ動作が行われ、<DIVIDE> エラーが返されるようになります。

PHANTOM が Login 動詞を実行するようになる

このリリースでは、PHANTOM の処理が変更されました。PHANTOM は起動したときに、LOGIN 動詞を実行するようになります。また、PHANTOPM は CHAIN および EXIT コマンドもサポートするようになります。

Internet Explorer での Zen の showModalDialog 関数の変更

Zen は、ポップアップ・ウィンドウを作成するユーティリティ関数 zenLaunchPopupWindow を定義します。この関数がサポートするオプションの 1 つに "modal=true" があります。以前のリリースでは、この関数は Internet Explorer を検知し、特別な IE 拡張 showModalDialog を使用していました。しかし、この目的で使用するには、この関数は信頼性が低いことがわかっています。このリリースでは、Zen は次のようにしてモーダル動作を実装します。

1. モーダル・モードで zenLaunchPopupWindow が呼び出された場合、Zen はそのページのモーダル・ハンドラをオンにし、ページ全体に透明な領域を配置して、モーダル領域以外で行われるマウス・クリックをすべてトラップします。

2. zenLaunchPopupWindow は、モーダル動作の最後をトラップするためのサロゲート・コールバックをセットアップします。具体的に言うと、ユーザがモーダル・ポップアップ以外の場所をクリックすると、Zen により、フォーカスがポップアップに戻されます。

pieChart で seriesNames および labelValues に対する制約の強制

このリリースより、次の制約が強制的に実施されます。

• pieChart では、seriesNames はリテラル値を含むことができません。

• pieChart では、seriesNames は xpath 式を複数含むことができません。

• pieChart では、labelNames は xpath を含むことができません。

pieChart で xpath を使用する必要がある場合は、seriesNames を使用します。pieChart でリテラル値を使用する必要がある場合は、labelNames を使用します。

xyChart に対する変更

バージョン 2010.2 で導入されたとき、色およびマーカの形状は、通常どおり、パターンの繰り返しになっていました。これでは実用性に限界があることが立証されています。今バージョンでは、Zen では、XY グラフで同じ dataField に属するポイントが、同じマーカおよび色を使用できるようになります。

生成された <apply-templates> のレポート名の前に / を入力してはならない

個々のサブレポートがデータのサブセクションを提供するようなサブレポートの使用を可能にするために、Zen では、今後、<xsl:apply-templates> 要素に表示されるレポート名の先頭に “/” は挿入されません。 これにより、PDF と HTML が同様に動作するようになります。

これにより、HTML で動作する使用事例が PDF でも動作するようになりますが、"reportname" ではなく "/reportname" を選択する <apply-templates> に依存した PDF レポートが存在する可能性があります。 このような ZEN レポートでは、reportname の前に明示的に "/" を入力することにより問題は解決されます。

SVG グラフ・コンポーネント

このバージョンでは、グラフ・クラス (棒グラフおよび折れ線グラフの親) における軸へのラベル付け方法が大きく変更され、新しいフラグ autoScaleText が導入されます。このフラグは既定では true に設定されています。

設定されている場合、軸のレンダラは、直前のグラフの動作をほとんど真似します。 このシナリオでは、テキストは描画にあわせて拡大されるため、グラフのアスペクト比が変更された場合、テキストが自動的に拡大され、歪んでしまう可能性があります。 このモードでの大きな変更は、X 軸に沿って大量のテキストが入力されていて、ラベルの印刷が重なる恐れがあるとき、ラベルの角度が指定されていない場合は自動的にテキストに角度が付けられ、値軸の場合は、わかりやすさのために一部のラベルが省略されるというものだけです。 軸にカテゴリ名がプロットされる場合、ラベルはすべて印刷されますが、確実に読めるようにするには、ユーザはフォントやレンダリングのサイズを調整する必要があります。これは以前のリリースとは異なる点です。

autoScaleText が false である場合、テキストはグラフ自体のサイズとは関係なく拡大されます (または、拡大されません)。 実際には、これは有効なフォント・サイズが最大フォント・サイズを表すことを意味します (非常に小さいグラフや煩雑なグラフでは、必要に応じて、フォントを縮小することもできます)。このアプローチにより、グラフのサイズを変更したときに、Zen がより効率的に空間を使用できるようになり、テキストの “標準” アスペクト比が、異なるレンダリング比で維持されるようになります。

このモードでは、軸のラベルも変更されます。 垂直軸の場合、連続する目盛りが付いているときには、限られたスペースにできるだけ多くの情報を重複することなく印刷できるように、印刷されるラベル・セットの多くが自動的に削除されます。 垂直にプロットされるカテゴリのラベルは、必要に応じてグラフに合うサイズに縮小されますが、ラベルが省略されることはありません。 水平軸では、ライン全体にわたってより多くの情報が表示されるように、まず、ラベルに角度が付けられます。 この操作を行っても、使用可能なスペースにすべてのラベルを表示できない場合は、範囲の値ラベルが大量に削除され、カテゴリ・ラベルが縮小されます。

simpleTablePane 用選択フォーカス

このバージョンでは、tablePanes の選択フォーカスの基本動作が変更されます。 これまでは、ある行をクリックすると、その行が選択 (selectionIndex プロパティが設定され、行がハイライト) されましたが、その後、選択した行をクリックしても、何も起こりませんでした。 選択フォーカスを変更するには、テーブルから別の行を選択する以外に方法はありませんでした。 これには、いったん、すべての行を選択したら、二度と選択を解除できないという影響がありました。

新しいシステムでは、選択されている行をクリックすると、選択が解除されます (テーブルの selectionIndex が -1 に設定され、ハイライトされている行はなくなります)。 これまでと同じ操作で選択フォーカスを変更することもできますが、現在選択されている行をクリックして、選択と選択解除を切り替えることができるという点が根本的に異なります。

さらに、このバージョンには onunselectrow コールバック・メカニズムが実装され、指定された行の選択が解除されたときに、ページ設計者に通知が送られるようになりました。 このイベントは、1 つの行の選択と選択解除を切り替えたとき、およびある行から別の行に選択フォーカスを変更したときの両方で発生します。 複数行の場合、unselectrow イベントがまず発生します。このときの selectionIndex は -1 です。 処理が完了すると、新たに選択された行番号を selectionIndex に設定した selectrow イベントが発生します。

フォーム・コントロールで使用される無効クラスの取り扱いの変更

これまでのバージョンでは、フォームに入力された無効な値には、controlClass 属性を通じて付けられた既存のクラス名を犠牲にして、DOM ノード・クラス名 zenInvalid というタグが付けられていました。 しかし、最近のすべてのブラウザでは、複数のクラスに同時に属するノードがサポートされているため、この二者択一の動作は必要なくなりましたが、実際のページ配置が混乱する可能性があります。

このバージョンでは、zenInvalid クラス・メンバシップは、完全に既存のクラス指定に取って代わるのではなく、このクラス指定を補足することができます。 これにより、controlClass と zenInvalid の両方が同じ CSS スタイルの設定を試みた場合 (例えば、テキスト・ボックスの背景色。zenInvalid はこれを赤にしようとします)、どちらのルールを優先するかという問題はブラウザに依存します。この問題は、zenInvalid クラスに設定された CSS ルールが、開発者により指定された controlClass に関連付けられているスタイルと直接競合しないようにすることで簡単に回避できます。

保存によるコンパイルは行われない

スタジオでは、“保存時にコンパイル” 機能のサポートを終了しました。 Save コマンドは常に保存操作のみを実行します。コンパイルは行いません。ユーザは、手動でコンパイル・オプションを選択する必要があります。このオプションは、コンパイラの動作設定から削除されました。

プロジェクトから XML へのすべての設定をエクスポートおよびインポート

このバージョン以前、スタジオでは、プロジェクトから XML エクスポート形式へは特性の設定のみエクスポートされていました。また、インポートされるのも特定の設定だけでした。今バージョンでは、これが変更され、便利な設定はすべて XML にエクスポートまたはインポートされるようになりました。

<Database> 作成属性の訂正

以前のバージョンでは、<Database> タグは、作成属性の値を適切に処理できませんでした。このタグは、“yes” と “overwrite” の値を区別できなかったため、どちらも “overwrite” が指定されているような動作をしていました。 このリリースでは、この属性に関するマニュアルの記述と一致するように、動作が訂正されています。