Caché 2015.1
この章では、Caché 2015.1 の以下の項目について説明します。
Caché 2015.1 の新機能と強化機能
今回のリリースでは、Caché に次の主な新機能が加わりました。
さらに、このバージョンの Caché では、次の分野の機能が向上しています。
さらに、これ以外にも、さまざまな点で機能強化や改善がなされています。特に既存のインストール環境をアップグレードする場合は、"アップグレード・チェックリスト" で詳細な変更内容を確認してください。
主な新機能
データベース・スケーラビリティの向上
このバージョンの Caché には、大規模なマルチコア・システムのパフォーマンスとスケーラビリティの向上を目的とした重要な変更があります。初期のベンチマークでは、16 コアから 64 コアまでのシステムについて、ほぼ線形のスケーラビリティを示します。インターシステムズは、パフォーマンスの観点からデータベース・エンジンを簡易化しました。また、これまでよりも効率の高いデータ使用アルゴリズムを導入して、さまざまなアプリケーションのアクセス・パターンに対するパフォーマンスを向上させています。これらの変更は、ほとんどのアプリケーションに効果がありますが、16 コアから 64 コアまでのスケーリングを活用しようとするアプリケーションでは、これまでに達成できなかった効果が得られるようになります。
迅速なアプリケーション開発
ステートレスなサービス要求
Java ゲートウェイの新しいステートレスなサービス要求機能により、実行中の Java サービス (新しい com.intersys.gateway.Service インタフェースを実装しているもの) に向けたコールアウトの単純化と効率の向上が可能になります。 パフォーマンスの向上に加えて、このゲートウェイ機能は、保存状態 (Ensemble プロキシが対応する Java のマップ先にマップされる方法) には一切依存しません。 引数と結果は、Ensemble 側では %Strings として表され、Java 側ではバイト配列として表されます。 これにより、シリアル化された値は、どのような値でも基盤となるエンジンとの受け渡しが可能になります。データ転送に使用される実際のワイヤ形式は JSON です。
XSLT2 のサポート
これまでのリリースで、インターシステムズは試験的なテクノロジ・プレビューとして、XSLT バージョン 2 のサポートを提供していました。今回のリリースでは、標準の Caché 構成の一部として、XSLT バージョン 2 の完全なサポートが提供されるようになりました。XSLT 2 は、XSLT バージョン 1 を大幅に上回る機能を備えています。主な新機能は次のとおりです。
-
より便利で表現力のある変換言語。XPath 2.0 および新しい XDM (XPath データ・モデル) もサポートしています。
-
強い型付け。XSL スキーマの型をサポートし、独自の (スキーマ) 型を定義することもできます。XPath 2.0 には、バージョン 1 には存在していなかった、新しいシーケンス型も含まれています。
-
大幅に強化された関数型言語。文字列処理、日時処理、ノードセット操作、およびブール演算子が向上されています。
-
xsl:function 命令による純粋な XSLT での関数の定義および記述機能。
これらを含む多数の向上機能および新機能により、あらゆる XSLT プログラマの生産性が大幅に向上します。 強力な型付けにより、多くのエラーをコンパイル時に捕捉し、すぐに修正できます。
XSLT バージョン 2 の機能は、%XML.XSLT2 パッケージに含まれるクラスを通じて利用できます。詳細は、"Caché XML ツールの使用法" の “XSLT 変換の実行” を参照してください。
XSLT2 の機能は、OpenVMS プラットフォームでは利用できません。
DeepSee の改善
今回のリリースには、DeepSee に対する多数の修正と機能向上が含まれています。特に重要なものは、以下のとおりです。
-
DeepSee クエリ監査
DeepSee は、常に、すべての MDX クエリに関する簡単なログを ^DeepSee.QueryLog に保持します。より詳細なクエリ監査を行うために、MDX クエリの実行時に毎回実行されるコードを定義できるようになりました。このコードでは、クエリ・テキストと、クエリに関連するその他の情報にアクセスします。"DeepSee 実装ガイド" の “ユーザ・アクティビティの監査” を参照してください。
-
新しい継続時間の形式
DeepSee のメジャーには、時間の長さを表す新しい形式が用意されています。メジャーが秒単位の継続時間を表している場合は、“%time%” という形式を使用することで、その値が hh:mm:ss の形式で表示されます。例えば、3800 秒は、01:03:20 という形式になります (1 時間 3 分 20 秒)。"DeepSee モデルの定義" の “形式文字列の指定” を参照してください。
-
%TIMERANGE 関数の拡張
%TIMERANGE 関数 (インターシステムズによる MDX への拡張機能) は、リレーションシップをサポートするようになりました。"DeepSee MDX リファレンス" を参照してください。
ソフト・モーダル・ダイアログ
Caché 2012.2 には、ソフト・モーダルという新機能が組み込まれていました。ダイアログ用に新しいウィンドウをポップアップ表示するのではなく、コードによって単に現在のページ DOM の上部に <div> レイヤを描画し、そのレイヤにダイアログを表示します。ダイアログの要件が満たされると、その <div> はクリアされます。この機能は、ポップアップが新しいタブ・ブラウザ・インスタンスを開くようなタブレットやモバイル・デバイスに対して特に適した動作を提供します。
バージョン 2012.2 では、この機能は導入されていましたが、既定では有効化されていませんでした。今回のリリースでは、このスイッチが反転されていて、ソフト・モーダルが既定の動作になりました。これは、^%ISC.ZEN.useSoftModals のグローバル・ノードを変更するか、%OnUseSoftModals() の既定の動作が false を返すようにオーバーライドすることで上書きできます。この変更は、ベース・クラスで行うことも、顧客の要求に応じてページに対してページごとに行うこともできます。
Zen Mojo
Zen Mojo は、2014 年の 3 月にスタンドアロン・キットとして初めてリリースされたものであり、2013.1 以降のバージョンの Cache および Ensemble にインストール可能でした。今回のバージョンからは、最新サポート対象バージョンの Mojo も事前にインストールされた状態で出荷されます。スタンドアロン・キットは、これまでどおり利用可能になり、メジャー・プラットフォーム・リリースとは別に更新されます。
Zen Mojo の詳細は、"Using Zen Mojo" および "Using Zen Mojo Plugins" を参照してください。
パフォーマンスとスケーラビリティ
セマフォ
今回のリリースでは、Caché アプリケーションにセマフォを導入しています。セマフォは、プロセス間 (特に、ECP システム上で実行しているプロセス間) のシグナル処理、制御および同期のために高速で効率の高いメカニズムを提供します。セマフォの使用方法の詳細は、クラス・ドキュメント、%SYSTEM.SemaphoreOpens in a new tab、またはセマフォに関する技術情報を参照してください。
NGINX Web サーバのサポート
今回のリリースには、CSP、Zen および Zen Mojo のための新しい Web サーバ・プラットフォームになる NGINX Web サーバのサポートが含まれています。NGINX は、高性能なイベント駆動型の Web サーバ・テクノロジであり、IIS と Apache に加えて、もう 1 つの選択肢として利用可能です。
信頼性、可用性、保守性、監視
より堅牢なミラーリング
今回のリリースでは、ミラーリング機能に、アービターと呼ばれる個別のシステムを採用するようになりました。これにより、プライマリのホストが完全に停止した状況や隔離されるようになる状況の障害シナリオからの安全な組み込み型の自動フェイルオーバーがサポートされるようになり、可用性は大幅に向上し、構成は簡単になります。このようなシナリオからのフェイルオーバーは、これまでは不可能でした。これが発生した場合、バックアップが引き継ぐことができます。それは、アービターによってそれとプライマリとの通信が途絶えたかどうかが確認され、プライマリが稼働している場合は、プライマリとしての機能を停止し、両方のフェイルオーバー・メンバがプライマリとして機能してしまう可能性が排除されるためです。
さらに、今回のリリースには、ミラーの構成、配置および管理を簡単にすることを目的とした、以下に示す進行中の一連の機能向上が含まれています。
-
"ミラーリングのアーキテクチャおよび計画" は、配置の計画段階で考慮する詳細のすべてに能率的にアクセスできます
-
[ミラー・モニタ] では、より包括的な情報が利用できます
-
SSL セットアップの問題についての構成時検出が向上しています
セキュリティ
複数のデータベース暗号化キー
今回のリリースから、インターシステムズ製品のユーザは複数の暗号キーを使用できます。この機能強化により、異なるデータベースに個別の暗号化キーを使用できるようになります。この機能により、将来のリリースではデータベースの再暗号化も可能になる予定です。
早期導入機能
このカテゴリの目的は、インターシステムズが既存および将来のアプリケーションの有効性を高めるために役立つと確信している新しいソフトウェア機能を紹介し、利用可能にする方法を提供することです。
ここに示す機能は、ユーザがいつでも使用できますが、機能や設計の面でまだ完全ではありません。これらの機能を利用するユーザは、以下の点を理解する必要があります。
-
インターシステムズでは、この機能が現在の形式で一般利用できるようになることを保証しません。
-
今後の更新があったとしても、このバージョンとの下位互換性についての保証はありません。
-
ユーザは、これらの機能を配置済みのアプリケーションに組み込むことができますが、その前にインターシステムズに問い合わせて、最善の対策を決定する必要があります。
-
これらの機能をアプリケーションに導入するユーザは、最終リリース・バージョンへのアップグレードを確約する必要があります。
ソフトウェアにこれらの項目を組み込むユーザには、自身の経験に関するフィードバックを提供することを強くお勧めします。
Enterprise Manager
インターシステムズは、Caché および Ensemble 2015.1 に伴う更新バージョンの Enterprise Manager をリリースしません。Enterprise Manager 2014.1 は、早期導入アプリケーションとして、引き続き Caché および Ensemble 2014.1 で利用可能になります。
Enterprise Manager の早期導入プログラムに参加して、新しい機能 (ネームスペース・サービス、マッピング変更時の自動データ移動、複数段階の承認、エクスポートおよびインポートなど) を使用する場合は、Andreas Dieckow (Andreas.Dieckow@intersystems.com) 宛にお問い合わせください。
予測分析
今回のリリースの Caché には、PMML (Predictive Modelling Markup Language) 標準バージョン 4.1 を使用して定義された予測モデルの実行時サポートが導入されています。データ・マイニングやモデリングのために、サードパーティ製のツール (KNIME、R、SAS、SPSS など) を使用して予測モデルを作成するデータ・サイエンティストやアナリストは、そのようなモデルの PMML 表現を Caché にインポートできるようになりました。このモデルのコンパイル時に、自動的にコードが生成されるようになり、アプリケーション (またはビジネス・プロセス) では、コンパイルしたモデルを Caché から直接 (サードパーティ製のツールに接続したり依存したりすることなく) 呼び出すことができます。Caché が導入した PMML の実行時サポートにより、Caché を使用した運用環境での従来の予測モデリング・アクティビティが活用できるようになります。
PMML の詳細は、ここOpens in a new tabを参照してください。また、このリリースに付随する技術資料も参照してください。
テキスト・カテゴリ化
テキスト・カテゴリ化により、単なるテキスト・フラグメントに基づいて、コンピュータでラベルを割り当てたり、アクションを呼び出したりできるようになります。今回のリリースの Caché には、テキスト・カテゴリ化モデルの構築と実行のためのフレームワークが導入されています。ユーザは、トレーニング・セットと呼ばれるカテゴリ化済みのテキスト・フラグメントのセットを基にして、カテゴリ化モデルを構築できます。iKnow によって識別されたテキストの主な機能を選択してから、モデルのタイプを選択することで、自動的にモデルを生成できます。このようなモデルは、トレーニング・セットから独立した状態で運用環境に配置できます。それ以降、ビジネス・プロセスやカスタム・アプリケーションの ObjectScript や SQL から呼び出すことができます。
テキスト・カテゴリ化について学習する場合は、この主要な研究報告書Opens in a new tabを参照してください。
Caché 2015.1 アップグレードのチェックリスト
このセクションでは、Caché 2015.1 の機能のうち、今回のバージョンで変更されたために、既存のシステムの管理、運用、または開発の作業に影響を及ぼすものを取り上げます。
前回リリースよりも前のリリースからアプリケーションをアップグレードする場合は、その中間に存在するリリースのアップグレード・チェックリストにも目を通すことを強くお勧めします。このドキュメントでは、2014.1 と 2015.1 の違いのみを取り上げています。
このドキュメントの冒頭に記載したアップグレードの説明は、このバージョンに適用されます。
管理者
このセクションでは、以前のバージョンの Caché の管理作業を熟知しているユーザを対象に、バージョン 2015.1 の管理に関する新機能と変更点を説明します。ここでは、各項目について簡単に説明します。ほとんどの場合は、ドキュメントの別の箇所に詳しい説明があります。
バージョン間の相互運用性
前回リリースとの相互運用性を示すテーブルが、サポート対象プラットフォームのドキュメントに掲載されています。
管理ポータルの変更
今回のリリースでは、新機能に対応し、また、既存マテリアルを使用しやすく構成し直すため、管理ポータルに多数の変更が加えられています。主な変更点の 1 つは、Caché のミラーリングとロールの使い分けに役立つページが追加されたことです。
操作上の変更
ここでは、システムによる処理方法に影響を与える変更について説明します。
<STORE> のエラー処理の変更
今回のリリースでは、Caché での低いメモリ状態の処理方法が変更されており、プロセスの最大メモリを超えているために <STORE> エラーが発生しているアプリケーションの回復を、エラー・ハンドラの特殊なコードを必要とすることなく、より適切に行えるようになりました。バージョン 2012.1 から 2014.1 までは、プロセスによって <STORE> エラーが生成されると、$ZSTORAGE の最大メモリが自動的に 1MB 増やされ、追加メモリが提供されてエラーが処理されていました。ただし、最初の <STORE> エラーのクリーンアップ後にアプリケーションによって $ZSTORAGE が明示的にリセットされない限り、次の <STORE> エラーでは追加のメモリの恩恵を受けられませんでした。
今回のリリースでは、<STORE> エラーの後にアプリケーションがメモリを解放すると、最初の <STORE> エラーで使用できたものと同じ追加の 1MB をその後の <STORE> エラーでも利用できるモードに戻ります。この新しいアプローチの詳細は以下のとおりです。
-
$ZSTORAGE は、プロセスによって <STORE> エラーが生成されたときに、変更されることはなくなりました。
-
$STORAGE は負の値になることもできるようになりました。
-
<STORE> エラーは、内部メモリのカウントではなく $STORAGE の値に基づいてスローされ、より予測しやすくなりました。
$ZSTORAGE の自動的増加 (2012.1 ~ 2014.1 の動作) に関する前提を設けているアプリケーション・エラー処理コードは見直す必要があります。さらに、$STORAGE が正の値であることに依存しているコードも見直す必要があります。この動作の詳細は、"Caché プロセスのメモリ" を参照してください。
%-ルーチンパスの設定は特権を必要とする操作
今回のリリースから、$ZU(39) または %SYSTEM.Process.SysRoutinePath() でのパーセント・ルーチンのプロセス検索パスの変更は、特権を必要とする操作になりました。プロセスは、CACHESYS データベースに対する Write 許可を持っている必要があります。パーセント・ルーチン・パスが、既定ではない値に設定されており、かつ ROUTINE^%R が使用されて現在のネームスペース以外のもので動作する場合、その処理が完了した後に Caché によって <PROTECT> エラーがスローされます。ルーチン・パスはリストアされません。
特権のないプロセスに標準以外のパーセント・ルーチン・パスを設定しているユーザは、パスを設定するための安全なメソッドを指定するか、標準以外のパスを必要としないようにそれらのコードを変更する必要があります。
^cspRule の再配置
今回のリリースでは、^cspRule の場所が既定のグローバル・データベースからルーチン・データベースに移動されています。以前のバージョンから 2015.1 へのアップグレードへの一部として、それらの CSP ルールを再コンパイルすることが必要になります。
ルーチン・キャッシュに使用される既定のメモリの増加
今回のリリースでは、メモリの自動構成を選択した場合に、ルーチン・キャッシュに割り当てられるメモリの量が約 12MB に拡大されました。 この変更の結果、これを明示的に指定していない構成では、ルーチンで消費する共有メモリが増加します。
%SYS.SYSTEM.GetNodeName() の変更
メソッド %SYS.System.GetNodeName(1) は、オペレーティング・システムが実行されているシステムに対して定義されているノード名を、そのオペレーティング・システムに返すように記述されています。以前のリリースでは、ノード名が取得され、それが大文字に変換されていました。現在では、ノード名はシステムによって定義されているとおりに返され、大文字に変換されなくなりました。
ターミナルの Control-C 入力の処理の変更
以前のリリースでは、一部のターミナル入力処理でターミナルからの読み取りの前に、保留中の Control-C シグナルがすべて解消されていました。その他のターミナル入力処理は、ターミナルからの読み取りの前に保留中だった Control-C のすべてが直接作用していました。 現在では、すべてのターミナル読み取り処理で、ターミナルからの読み取りの前に保留中の Control-C が解消されます。
インタラクティブな入力に対して先行入力を行う習慣があるユーザは、読み取りが開始された後に 2 度目の Control-C の入力が必要になります。先行入力の Control-C は、入力処理で無視されるようになりました。また、現在は、ターミナル先行入力バッファのコンテンツをクリアする操作 (例えば、WRITE *-1 や WRITE *-10 を使用) により、先行入力バッファが空になるのと同時に保留中の Control-C も解消されます。
ユーザがターミナル入力処理に応答して直接 Control-C を入力する場合の動作に変更はありません。
引数なしの QUIT コマンドのエラー・レポートの変更
関数が値を返す必要があるときに引数なしの QUIT で終了する場合、<COMMAND> エラーにより、QUIT (ルーチンまたはプロシージャの終わりに暗黙的に含まれていることがある) の場所がレポートされるようになりました。$ZERROR およびエラー例外オブジェクトには、関数が値を返す必要があることを示すデータ・フィールドがあります。
ルーチンがそれ自体内の <COMMAND> を確認することでこの状態を検出する場合、$ZERROR でのルーチン名は異なったものになるため、この確認は失敗します。このテストは、“*Function must return a value” というテキストを検索するように変更できます。
$INCREMENT が障害時にエラーを通知
以前のリリースでは、$INCREMENT がエラーの通知に失敗することがありました。式が以下のとおりで、
$INCREMENT(X, Y)
非ゼロの Y 値があり、X の値の変更に失敗した場合などです。そのような状況は、例えば、X が整数値で Y が小さい小数 (約 5E-19*X 未満) である場合や、X に 10 進数値が含まれており、Y が小さい $DOUBLE バイナリの小数 (約 $DOUBLE(1E-16)*X 未満) である場合に発生することがありました。
現在は、Y が非ゼロの場合の X の値の変更の失敗は、常に <MAXINCREMENT> エラーとなります。
ゼロの Y 値 (X のインクリメントなし) は有効であり、そのような場合にエラーが通知されることはありません。
ミラーリングの変更
-
ミラー・データベース名が Config.Database データセット名に関する検証に合格することが必要
ミラー・データベース名は、旧システムの既存のデータベースとの互換性のために大文字でも小文字でも入力できますが、大文字で格納されるようになりました。既存のミラー・データベース名がこの変更によって影響を受けることはありません。したがって、大文字小文字の区別のみが異なる名前で 2 つのミラー・データベースを作成することはできなくなりました。さらに、ミラー・データベース名に有効な文字のみが、データセット名に使用される文字です。先頭の文字は、英字またはアンダースコアである必要があり、残りの部分は英字、ハイフンおよびアンダースコアの連続したものである必要があります。
-
syncrule_ack 以外のミラー同期ルールの削除
今回のリリースから、ミラーリングにおいて複数の応答モード (Sync、Acked、Committed) はサポートされなくなりました。 詳細ミラーリング構成オプション Acknowledgement Mode は削除されました。以前のリリースでは、既定ではない値である “Committed” を選択すると、不要な副次的作用が発生することがあり、信頼性や堅牢さにおける向上はありませんでした。
-
エージェントの通信のアービターへの置き換え
新しいミラーリング機能にはアービターという別個のシステムが採用され、可用性が大幅に高まり、構成が単純化されました。それは、プライマリのホストで壊滅的な障害が発生したかそれが分離された場合における、以前は不可能であった障害シナリオで、安全な組み込みの自動フェイルオーバーがサポートされるようになったためです。これが発生した場合、バックアップが引き継ぐことができます。それは、アービターによってそれとプライマリとの通信が途絶えたかどうかが確認され、プライマリが稼働している場合は、プライマリとしての機能を停止し、両方のフェイルオーバー・メンバがプライマリとして機能してしまう可能性が排除されるためです。
以前のバージョンでは、これらの障害シナリオの 1 つが発生すると、バックアップにはプライマリの障害とネットワークの分離とを区別する方法がなく、プライマリがプライマリとして機能しなくなったことを確認できず、既定では、この状況でバックアップが自動的に引き継ぐことはできませんでした。特別な条件の下では、ユーザが指定した IsOtherNodeDown エントリ・ポイントを ^ZMIRROR ルーチンに追加し、[フェイルオーバーにエージェントの通信が必要] 設定をクリアすることでこの状況で自動フェイルオーバーを有効化することができました。ただし、プライマリが停止していることを確認するための完全に信頼できるメカニズムを実装することは、大部分の環境で不可能ではなくても困難です。その結果、この方法の大部分のユーザは、まれなケースとしても、場合によっては、両方のフェイルオーバー・メンバが同時にプライマリとして機能するリスクを受け入れていました。
2015.1 以降は、このメカニズムは排除され、アービターベースのフェイルオーバー・メカニズムに置き換えられています。組み込みのアービター機能は、一般的に、完全に安全な方法でカスタム・コーディングを必要とすることなく、障害シナリオに適切に対応します。2015.1 では、[フェイルオーバーにエージェントの通信が必要] 設定は削除され、^ZMIRROR の IsOtherNodeDown エントリ・ポイントは使用されなくなります。IsOtherNodeDown^ZMIRROR を使用するサイトでは、2015.1 でプライマリ・ホストの障害に対する自動フェイルオーバーが実行されるようにするには、アービターを有効化する必要があります。
既存のミラーを 2015.1 にアップグレードしてアービターを有効化するには、次の手順を実行する必要があります。
-
アービターとして機能するシステムを "Caché 高可用性ガイド" の "ミラーの可用性を最適化するためのアービターの配置" の説明に従ってアービターとして機能するシステムを指定します(1 つのアービターを複数のミラーで共有できます)。
-
同じドキュメントの "アービターのインストール" の説明に従って、アービターをインストールおよび構成します。これには、最小のソフトウェアのインストールが含まれており、Caché がインストールされている必要はありません。
-
"Caché インストール・ガイド" の "最小ダウンタイムによるミラーのアップグレード" の説明に従って、ミラー・メンバをアップグレードします。
-
"Caché 高可用性ガイド" の "フェイルオーバー・メンバの編集または削除" の説明に従って、アービターを使用するようにミラーを構成します。
-
-
名前および昇格を管理するときの非同期メンバの選択に関する修正
非同期メンバの昇格および認証 ID の管理の一環としてミラー名の番号付きリストを表示する、^MIRROR のコードが変更されました。これは、数値の名前を持つミラー・メンバがある場合にも適切に機能するようになりました。以前は、数値の名前がリスト内の番号付き選択肢であるのか、メンバの名前であるのかについて混乱することがありました。認証 ID を管理する際のメンバの追加は、管理するメンバ名の入力を要求されたときに Add (および有効な名前) を入力することで起動される、別個の処理になりました。それ以外の場合、応答は最初にメンバ名として、次に (可能な場合) 数値リストの選択項目として処理されます。
-
ミラー・モニタ・ステータスのレポートに行われた変更
ミラー・モニタには、いくつかのレポートの変更があります。
-
[ミラー・メンバ・ステータス] というセクションに、[ジャーナル転送の遅延] と [ディジャーナルの遅延] に対してレポートされる新しい値があります。
-
[ミラー・データベース] セクションには、[ステータス] の新しい値が表示されます。
-
[ミラー・データベース・ステータス] の [遅延] 列の名前が [次にデジャーナルするレコード] に変更されました。
-
名前が変更された列には、ミラー・データベースの Timestamp、File Name および Journal Offset 位置が含まれています。フィールドは、コンマ (,) で区切られています。
ステータス値の詳細な説明は、"高可用性ガイド" を参照してください。
-
-
^MIRROR ユーティリティからの暗号化通信設定の削除
以前のバージョンでは、各ミラー・メンバの Encrypt Communication 設定を使用して、他のメンバから独立して SSL を使用するように個別のミラー・メンバを構成できました。今回のリリースでは、この設定は、ミラー構成画面から削除されました。
代わりに、Use SSL オプションを設定することで、すべてのメンバに SSL が必要となるようにミラーを構成することをお勧めします。Encrypt Communication 設定は、アップグレード中もメンバに対して保持され、Config.MapMirrorsOpens in a new tab クラスを使用して管理できますが、このオプションを使用するシステムは、実用後すぐに、推奨される Use SSL オプションに変更する必要があります。
-
起動時のフェイルオーバー・ミラー・メンバへのログインの防止
フェイルオーバー・ミラー・メンバ上のシステム・ワイド・セキュリティ・パラメータ Inactive Limit は、そのミラー・メンバが起動するたびにゼロに設定されます。このパラメータによって、未使用のアカウントを無効としてマークする間隔が制御されます。バックアップ・ミラー・メンバでアカウントが無効化されないようにするには、これをゼロに設定してこの機能を無効化します。 災害復旧メンバがフェイルオーバー・メンバに昇格された場合、これはその時点で同様にゼロに設定されます。
これに依存してアイドル・アカウントをクリーンアップしているサイトは、ミラーでは別の方法を採用する必要があります。
-
最大ミラー・メンバ数は 16
今回のリリースでは、各ミラー・セット内のミラー・メンバの最大数は、8 から 16 に増加しました。
Important:この変更を適切に実装するには、ミラー・セットのすべてのメンバをこのバージョンにアップグレードする必要があります。
ジャーナリングの変更
今回のリリースより前は、保留中のジャーナル入出力が存在するがジャーナルのアクティビティが 10 秒間ないとジャーナル・エラーでフリーズするように設定されていました。今回のバージョンでは、この時間制限が 10 秒から 30 秒に増やされました。10 秒が経過した時点で、次の警告メッセージが cconsole.log に生成されます。
Journal Daemon has been inactive with I/O pending for x seconds
以前の短いタイムアウトを想定している場合は、このしきい値を調整する必要があります。
通常のセキュリティ・インストールでのパブリック許可からの %Service_Object:U の削除
セキュリティ上の理由から、通常のセキュリティ・インストールでは %Service_Object:U はパブリック許可ではなくなりました。 %Service_Bindings クライアントが %Service_Object を使用するには、%Service_Object:U を持つロールが必要になります。 %Developer および %Manager はこの許可を持ち、他のものは必要に応じて追加できます。通常のセキュリティ・インストールのスタジオのユーザは、%Service_Object:U を持つロールを必要とします。
<NOCATCH> エラーの名前の <THROW> への変更と例外オブジェクトの処理の変更
THROW が存在し、それを捕捉する一致する TRY/CATCH が存在しない場合に発生する <NOCATCH> エラーは、<THROW> という名前に変更されました。さらに、そのオブジェクトは、すぐに終了する代わりに特殊変数 $THROWOBJ に保存されるようになります。これにより、エラー・トラップがオブジェクトにアクセスして処理方法を決定することが可能になります。
捕捉されていない例外オブジェクトは、$THROWOBJ がクリアされるまで永続されるようになりました。例外オブジェクトが、解放する必要があるリソースを保持している場合は、オブジェクトの存続期間が長いことに問題がある可能性があります。エラー・トラップで $THROWOBJ を空の文字列に設定し、例外オブジェクトが不要になったときにそれを終了する (およびリソースを開放する) 必要があります。
CACHESYS の % ルーチンでの +offset を使用した DO/GOTO の不可
DO および GOTO の +offset 構文を使用して CACHESYS データベースに %-routines の入力を試みることは不正になりました。これが検出されると <NOLINE> エラーがスローされます。
%Status 値を返すようになった SYS.Agent.VerifyConnection
失敗した VerifyConnection() 呼び出しの戻り値が変更されました。結果は、“0” ではなく %Status 値になります。 これは、アプリケーション・コードでブーリアン演算子を使用する代わりに、このメソッドの戻り値を直接 “0” と比較する場合にのみ、非互換が発生します。例えば、以下のようになります。
If ##class(SYS.Agent).VerifyConnection() = 0
は、現在は、VerifyConnection が失敗した場合に機能しません。検証が成功すると、$$$OK が返されます。これは、値 1 と同一であり、変更されていません。
CacheSSH の戻り値の変更
%Net.SSH.SFTPOpens in a new tab クラスには、リモート・ディレクトリのコンテンツを列挙するメソッド Dir() があります。以前のリリースの既定の動作では、“.”、“..”、“.rc” など、“.” で始まるディレクトリ・エントリ名が返されました。現在は、SFTP インタフェースの規約に従って、これらのファイルは既定では除外されています。以前の動作は、Dir() の新しいオプションの 4 番目の引数を true に設定することでリストアできます。
アプリケーションで、一致する名前に特定のパターンが指定されている場合、それが既定の動作よりも優先されます。
クラス記述子キャッシュの注意深い管理
Caché では、以前は、共有クラス・キャッシュの最大サイズはシステムのルーチンの数の割合に設定されていました。この数値が大きすぎる値に設定されていると、多数の一意のクラスが呼び出される場合に、クラス・キャッシュの共有ヒープがすべて使用される可能性がありました。 今回のリリースでは、共有クラスの制限が 900 に設定されています。
これは、小さな固定セットのクラスが実際にシステムで使用されている場合は問題になりません。 大きいセットのクラスが使用されている場合、システムですべてのクラスをキャッシュできない可能性があります。このインスタンスがパフォーマンスに影響を与えることがあります。その場合、キャッシュされるクラスの制限を手動で調整できます。インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。
新しいルーチンに切り替えられない XECUTE の ZSAVE
コマンド・プロンプトから実行される場合、ZSAVE は、現在のルーチンをコマンドで指定されているものに切り替えます。以前のリリースでは、以下の文を実行し、
XECUTE "ZSAVE SomeRoutine"
新しいルーチンに切り替えることができました。ただし、これが XECUTE 内で実行される場合、初期設定されていない変数が原因でクラッシュが頻繁に発生します。
今回のリリースから、このコマンドでは新しいルーチンに切り替えることはできません。
エラー削除タスクではネームスペースではなくローカル・データベースを使用
^ERRORS グローバルは、システム・タスクによって定期的に削除されます。以前のリリースでは、タスクが実行されると、そのタスクは、タスクを実行しているマシンにローカルな既定のデータベースのネームスペースごとに ^ERRORS グローバルを削除していました。このため、データベースが存在していても、定義されたネームスペースが存在しない場合に問題が発生しました。この場合、^ERRORS グローバルは削除されず、サイズが大きくなる可能性がありました。
今回のリリースでは、タスクはローカル・システム上で定義されている各データベースを .cpf ファイルの [Databases] セクションで定義されているとおりにループするようになりました。定義されているデータベースごとに、次の条件が確認されます。
-
データベースが ECP データベースである。
-
データベースがミラーリングされており、タスクを実行しているシステムがプライマリではない。
-
データベースが読み取り専用である。
-
データベースがディスマウントされている。
これらの条件のいずれかに該当する場合、そのデータベースに対する削除はスキップされます。 最後の条件については、データベースはシステムにまだマウントされていない場合、Caché によってそれのマウントが試みられ、その条件がテスト可能になります。
共有ライブラリの参照カウントでの管理
以前のリリースでは、$ZF(-4, 1, <PathToLibrary>) によってライブラリが複数のクラスによってロードされていたり、$ZF(-6, <index>, <Function>, <arg1>, <arg2>, ...) の呼び出しによってライブラリがロードされた場合であっても、$ZF(-4, 2, <LibraryHandle>) の 1 回の呼び出しでライブラリはすぐにアンロードされました。
現在は、$ZF(-4, 1) により 1 つのライブラリがロードされた回数の参照カウントが保持されるようになりました。 $ZF(-4, 1, <PathToLibrary>) の呼び出しごとに、参照カウントが増加します。 $ZF(-4, 2, <LibraryHandle>) の呼び出しごとに、参照カウントが減少し、参照カウントがゼロになるとライブラリがアンロードされます。
ライブラリ・ハンドル引数が指定されていない $ZF(-4, 2) では、すべてのライブラリがアンロードされ、この動作に変更はありません。 参照カウントに関係なくすべてのライブラリがすぐにアンロードされます。
現在は、$ZF(-4, 1, <PathToLibrary>) によるライブラリのロードと、$ZF([-4, 5 or 7], <index>, <path>) の呼び出しによってライブラリ・インデックスが事前に構築された $ZF(-6, <index>, <function>, <args>) によるライブラリのロードの間には、ある程度の独立性があります。 $ZF(-4, 1, <path>) によってロードされたライブラリは $ZF(-4, 4, <index) の呼び出しによってアンロードされず、$ZF(-6, <index>, <function>, <args>) によって明示的にロードされたライブラリは $ZF(-4, 2, <LibraryHandle>) によってアンロードされることはありません。 ただし、<LibraryHandle> 引数が指定されていない $ZF(-4, 2) では、すべてのライブラリがそのロード方法に関係なくアンロードされます。
%SYS.ProcessQuery – ClientNodeName、StartupClientNodeName、Current Device の長さの増加
以前のリリースでは、ClientNodeName および StartupClientNodeName の値は 32 文字までに切り捨てられ、Current Device の値は 24 文字までに切り捨てられました。今回のリリースでは、それら 3 つすべてで 64 文字まで切り捨ては行われません。
統一トリガ・メカニズムの明確化
オブジェクトおよび SQL に対する統一トリガのサポートは、バージョン 2014.1 で導入されました。ストリームであるフィールドまたはプロパティがトリガ定義内で参照される場合、その参照の値がストリームの OID です。
-
BEFORE INSERT または UPDATE として指定されたトリガについては、新しい値が INSERT、UPDATE または %Save 操作によって指定されている場合、{StreamField*N} は一時的なストリーム・オブジェクトの OID、または新しいリテラル・ストリーム値のいずれかになります。
-
BEFORE UPDATE トリガについては、新しいストリーム値がフィールドまたはプロパティに対して指定されていない場合、{StreamField*O} および {StreamField*N} は両方とも現在のフィールドまたはプロパティ・ストリーム・オブジェクトの OID になります。
$SYSTEM.TSQL 検証の追加
$SYSTEM.TSQL の “Set” メソッドでは、それらに渡されたパラメータ値が検証されるようになりました。“Get” メソッドは、それらが冗長であったため、パラメータを取らなくなりました。
^%SYSMONMGR メニューの変更
^%SYSMONMGR のオプション #4、“Manage Sensor Readings” のラベルは、“Manage Debug Data” に変更されました。
グローバル・マッピングでの文字シーケンス || の不可
グローバル・マッピングを定義するときに、文字シーケンス “||” はマッピングのいずれの場所でも許可されません。
Java 仮想マシン (JVM) のバージョンの要件
今回のリリースの時点では、Java 仮想マシンに依存する Caché 関数には 1.7 以降のバージョンの JVM が必要です。
Docserver アプリケーションの無効化
今回のリリースから、アプリケーション /csp/samples/docserver は、アップグレードおよび新規インストールで既定では無効化されています。
プラットフォーム固有の項目
このセクションでは、特定のプラットフォームに関係する項目について説明します。
Windows
-
UNIX® とのインスタンス値の一致
Windows 上で “ccontrol all” によって表示されるインスタンスの状態値は、UNIX® 上で表示される値と一致するように変更されました。 具体的には、状態テキスト “ab” が “ ” に変更されました。 ^STU が完了せずにインスタンスが部分的に起動している可能性がありログインが無効化されていることを空白の値は示します (インスタンスの状態値の完全なセットは “ccontrol help” によって表示されます)。
Windows 上で “ccontrol list” によって表示されるインスタンスの状態値は、UNIX® および OpenVMS 上で表示される値と一致するように変更されました。具体的には、状態の略記テキストが完全な用語に拡張されました。 この状態テキストは、“ccontrol help” によって表示される Web ページに記載されています。
-
8ビット・ロケールのパターン・マッチングの変更
以前のバージョンでは、範囲 128 ~ 159 の Windows コード・ページ (CP12xx) の未定義の文字は、パターン・コード “1E” (任意の文字に一致) によってのみ一致しました。今回のリリースから、それらは、“1C” (制御文字に一致) でも一致します。この変更の目的は、プログラムでのこれらの文字のフィルタ処理を容易にして、ターミナル出力の文字化けを回避することです。以下に、影響を受ける具体的な文字をコード・ページ別に示します。
-
CP1250:129、131、136、144、152
-
CP1251:152
-
CP1252:129、141、143、144、157
-
CP1253:129、136、138、140、141、142、143、144、152、154、156、157、158、159
-
CP1255:129、138、140、141、142、143、144、154、156、157、158、159
-
CP1257:129、131、136、138、140、144、152、154、156、159
CP1256 では 128 ~ 159 の範囲に未定義の文字はなく、CP1250 ではその未定義の文字が既に出力不能文字として (ただし、制御文字としてではなく) マークされています。パターン・マッチングの詳細は、"Caché ObjectScript の使用法" ガイドのパターン・マッチング演算子を参照してください。
-
-
Caché サービス・アカウントは Windows Administrators グループである必要はない
Caché サービス・アカウントは、Windows 上で大部分の Caché プロセスの実行に使用されますが、Windows Administrators グループのメンバである必要はなくなりました。 インストール中に Caché サービス・アカウントとして指定されたアカウントは、CacheServices グループのメンバになります。 CacheServices グループは、そのメンバに Caché インスタンスを起動、停止、および制御する制限されたセットの権限を付与します。 このグループのメンバシップは、Caché サービス・アカウントが以下のもので変更された場合にも付与されます。
cinstall setserviceusername <InstanceName> <username> <password>
この変更は、Caché をローカル・システム・アカウントとして、または管理ユーザ・アカウントとして実行することを選択した場合には何の影響も与えません。 Caché を非管理ユーザ・アカウントで実行することを選択した場合は、Caché サービス・アカウント (または CacheServices グループ) に、データベース、ジャーナルおよびログ・ファイルが配置されているすべてのディレクトリへの十分なアクセス権 (読み取り/書き込み/実行) と、ファイル自体への適切なアクセス権が付与されていることの確認が必要になることがあります。
UNIX®
-
Linux プラットフォームに対して推奨される TZ 環境変数の設定
Linux プラットフォームでは、TZ 環境変数の設定をお勧めします。この変数はタイムゾーンを示します。この変数が設定されていないと、Caché の時間関連関数のパフォーマンスが大幅に低下することがあります。この変数の設定の詳細は、tzset のマニュアル・ページを参照してください。
-
root 以外のインストールの禁止
今回のリリースから、Caché のインストールは root のユーザ ID で実行する必要があります。
Red Hat Enterprise Linux 7 (Power System-64)
このプラットフォームでの上記のオペレーティング・システムのバージョンは、現時点で Perl または Python をサポートしていません。
Light C++ Binding に影響する SUSE Linux 12 リンカの変更
SUSE 12 システムのリンカの変更により、Light C++ Binding アプリケーションの構築に障害が発生します。SUSE 12 リンカでは、リンク対象の他のライブラリの依存ライブラリを明示的に指定するために、アプリケーション makefile が必要になっています。これに該当する他のライブラリがリンクされるときに、依存ライブラリを指定していたとしても makefile は必要です。 この場合、libcachet.so は libpthread.so に依存するため、SUSE 12 Linux 以降は、両方のライブラリを明示的に指定する必要があります。そのため、アプリケーションを正常に構築するには、以下の変更の 1 つを実行する必要があります。
-
アプリケーションの構築に使用する makefile の ID または g++ コマンド行のライブラリ指定に –lpthread を追加します。 例えば、Light C++ バインディングのサンプル・アプリケーションでインストールした Master.mak ファイルの 1 つに基づいた makefile を使用する場合は、以下の行を変更します。
CACHETLIB = -L$(CACHETPATH) -lcachet
以下のように変更します。
CACHETLIB = -L$(CACHETPATH) -lcachet –lpthread
-
make が呼び出される環境で、環境変数 MULTITHREADED を 1 に設定します。 Bourne シェルでは、構文は以下のようになります。
export MULTITHREADED=1
この問題は、どちらのオプションでも解決できます。これらのオプションは競合しないため、両方のオプションを同時に使用できます。
OpenVMS
-
OpenVMS でのジョブの名前付けの変更
OpenVMS では、JOB コマンドでプロセス名を指定できます。このプロセス名が既に存在している場合、JOB コマンドによって <SYSTEM> エラーがスローされ、その結果、スタック・ダンプ・ログ (CERRSAVE-pid.LOG ファイル) も作成されます。このバージョン以降、エラーは、<INVALID ARGUMENT> エラーに変更され、ログ・ファイルは作成されなくなりました。
これは、特定の戻りコードをチェックするアプリケーションに対して互換性のない変更です。
-
Java 依存機能の利用不可
今回のリリースでは、Java の最小必要バージョンは 1.7 であると規定しています。OpenVMS 向けの最新の Java リリースは、バージョン 1.6 であるため、Java 仮想マシン (JVM) へのアクセスに依存するすべての機能 (Zen レポートなど) は使用できなくなりました。
Mac OS X
インターシステムズでは、GCC の使用から Clang/LLVM への Apple の切り替えに従っています。ただし、どの C++ 標準ライブラリを使用する必要があるのかは明白ではありません。 そこで Caché では、以下の 2 つのバージョンの使用をサポートしています。
-
libc++ – LLVM のより新しい C++11 互換バージョン
-
libstdc++ – GNU バージョン
アプリケーションでは同じプログラムで両方のバージョンを使用できますが、それらを組み合わせることはできません。つまり、一方から他方の関数に std::string を渡すことはできません。Caché はカスタム char 型を使用するため、明示的に古いほうの GNU libstdc++ が使用されます。
ODBC とリンクする C++ ユーザまたは ObjectiveCache を使用する Objective-C ユーザにとって相違点はありませんが、C++ バインディング・ユーザは、std:: ネームスペース (std::string など) のクラスを処理する C++ バインディング API を使用する場合は、それらのビルド・フラグに “-stdlib=libstdc++” を追加する必要が生じることもあります。
開発者
このセクションでは、以前のバージョンの Caché 上で実行されているアプリケーションの設計者、開発者、および保守担当者に関係する情報を示します。
ここでは、各項目について簡単に説明します。ほとんどの場合は、ドキュメントの別の箇所に詳しい説明があります。
ルーチンの変更
%SYS.GSIZE から %GSIZE への名前の変更
%SYS.GSIZE を呼び出していたアプリケーションは、元の名前である %GSIZE を呼び出すように戻し、再びそれを CACHELIB の一部とする必要があります。データベースに対する特権を持たないユーザには、どのグローバルが存在しているかや、そのグローバルのサイズを確認できないようにする必要があります。
ルーチン・コンパイラの変更
文内のコメントの処理の変更
次の 2 つの文について考えてみましょう。
_________A________ _________B________ Line 1 If (i = 1) {} If (i = 1) {} Line 2 ElseIf (i = 2) {} ElseIf (i = 2) {} Line 3 // comment ;; comment Line 4 Else Set I = 5 Else Set I = 5
“A” 文のシーケンスは不正であり、コンパイルされません。それは、それに Caché IF...ELSEIF 文とそれに続くレガシー ELSE 文が含まれているためです。A の行 3 にあるコメントは無視されるため、Caché IF 構文を従来の行型 IF 構文と組み合わせることは不正です。
今回のリリースより前は、“B” シーケンスはコンパイルされました。それは行 3 の “;;” コメントが Caché IF 文の構文分析を終了させており、それによって従来の ELSE 構文が正当であるとして受け入れられたためです。
現在は、“;;” コメントは終了括弧の後に受け入れられ、“B” 文シーケンスは “A” シーケンスと同様に分析されます。 これは、現在は、コンパイルされると構文エラーが生成されます。
クラスの変更
クラスの削除
以前のバージョンに存在していた以下のクラスは、このリリースで削除されています。
-
%CSP.UI.Portal — UsersParameters
-
%CSP.UI.Portal.Dialog — DatabaseWizardEMS、ServiceConnections
-
%CSP.UI.System — AuditPane、AuditSearchPane、ManageAuditPane
-
%DeepSee.DomainExpert.components — MetadataValues
-
%Net.Remote.Java — JDBCGateway
-
%SYS — Monitor
-
%iKnow.Classification — ClassifierProjection、LinearBuilder、NaiveBayesBuilder
-
%iKnow.Classification.Definition — Term、Transformation
-
%iKnow.Compiler — LexrepIdeographicStateOutputFunction、MetadataTable、PreprocessOutputFunction
-
%iKnow.Objects.tfidf — MetadataAnalyzer
-
%iKnow.Queries — EquivAPI
-
%iKnow.UI — ITablesLoadingWizard
-
%iKnow.UI.Dialog — Classifier
-
%iKnow.ont — SourceMatches、TableGenerator、TableManager
-
SYS — Volume
-
Security — Common
クラス・コンポーネントの削除
このバージョンでは、以下のクラス・コンポーネントが、以前に存在していたクラスから移動または削除されています。
クラス | タイプ | 名前 |
---|---|---|
%CSP.Documatic.CubeInfo | メソッド | DrawOverLvl、DrawOverProp |
%CSP.Portal.Template | メソッド | ZStripW |
%CSP.Portal.standardDialog | メソッド | ZStripW |
— | プロパティ | EMSGroupName、IsEMSGroup |
%CSP.UI.Component.RoleMemberTab | プロパティ | SelectedItems、emsGroupName |
%CSP.UI.Component.SQLPrivileges | プロパティ | emsGroupName |
%CSP.UI.Component.SQLTables | プロパティ | emsGroupName |
%CSP.UI.Component.abstractRoleTab | プロパティ | emsGroupName |
%CSP.UI.Portal.Applications.Web | プロパティ | PermittedClassTitle |
%CSP.UI.Portal.Database | プロパティ | isMirror |
%CSP.UI.Portal.DatabaseTemplate | メソッド | LoadErrorMessage |
— | プロパティ | OldReadOnly、RestartMessage |
%CSP.UI.Portal.Dialog.EncAddAdmin | メソッド | ZStripW |
%CSP.UI.Portal.Dialog.RemoteDatabase | メソッド | ServerIsManaged、changeServerEMS |
— | プロパティ | MsgNotManaged |
%CSP.UI.Portal.Dialog.Service | メソッド | showConnections |
%CSP.UI.Portal.EncryptionDatabase | メソッド | doSetDefault |
— | プロパティ | lblSetDefault |
%CSP.UI.Portal.Mirror.Dialog.AsyncEdit | メソッド | DrawEncrypt、SaveData、doSave |
%CSP.UI.Portal.Mirror.EditFailover | メソッド | DrawMemberInfoTable |
— | プロパティ | OtherMemberECP、OtherMemberName、OtherMemberPrivateAddress、ThisMemberECP、ThisMemberName、ThisMemberPrivateAddress |
%CSP.UI.Portal.Mirror.JoinAsync | メソッド | changeSSL |
%CSP.UI.Portal.NLS | メソッド | saveLocale |
%CSP.UI.Portal.SQL.Home | プロパティ | FILTER |
%CSP.UI.Portal.Shadow | メソッド | refreshTable |
%CSP.UI.Portal.Template | プロパティ | EMSGroupName、IsEMSGroup |
%CSP.UI.Portal.ViewLog | プロパティ | FILENAME |
%CSP.UI.Portal.iKnow.Dialog.AddDomainConfig | メソッド | browseSelect、changeLang |
%CSP.UI.System.MappingsAPI | メソッド | DrawMapJS、PrepareInsert |
%CSP.UI.System.Mirror | プロパティ | MemberStatusList、MirroredDatabaseList |
%DeepSee.DomainExpert.queries.IK | メソッド | %DefAtuiClassName |
%DeepSee.PMML.Builder.AbstractBuilder | メソッド | GeneratePMMLAsString、GeneratePMMLClass |
%DeepSee.PMML.UI.ModelTester | メソッド | BuildRowDetailsQuery、CheckSQL、DrawCategorizedText、DropTestResults、ExportToCubeDefinition、GetConfusionMatrix、GetTestResults、OnGetSQLAccuracy、OnGetSQLCatValDetails、OnGetSQLErrors、OnGetSQLScatter、changeModel、export、launchExport、onCatValElementClick、onTestModel、setConfusionMatrixValue、showText、test、updateCatValDetails |
— | プロパティ | currentActualValue、currentPredictedValue、currentRowId、customSQL、definitionClass、highlightedSentencesOnly、mode、modelType、testId、verParamPrecision、verParamZeroThreshold |
%DeepSee.Report.UI.BuildLIDR | メソッド | reallySaveDCR |
%DeepSee.Report.UI.abstractIconBar | プロパティ | titleList、valueList、widgetList |
%DeepSee.Report.UI.alignIconBar | プロパティ | titleList、valueList、widgetList |
%DeepSee.Report.UI.arrangeIconBar | プロパティ | titleList、valueList、widgetList |
%DeepSee.Report.UI.editIconBar | プロパティ | titleList、valueList、widgetList |
%DeepSee.Report.UI.layerIconBar | プロパティ | titleList、valueList、widgetList |
%Installer.InstallerWizard | メソッド | ZStripW |
%Library.CacheSQLStorage | メソッド | %BuildIndices |
%Library.CacheStorage | メソッド | %BuildIndices |
%Library.Persistent | メソッド | %CheckUnique |
%Net.Remote.Gateway | メソッド | %PopDeviceStack、%PushDeviceStack |
— | プロパティ | DeviceStack |
%Net.Remote.Java.XSLTGateway | メソッド | ConnectGateway |
%Net.Remote.ObjectGateway | メソッド | GatewayState |
%SYS.Monitor | メソッド | RefreshSensors、SaveSensors |
%SYS.Task.PurgeZENReports | プロパティ | FileLifeTime |
%SYSTEM.Process | メソッド | KillAllPrivateGlobals |
%SYSTEM.WorkMgr | メソッド | SignalAll、StopWorkers |
%UMLS.Utils | メソッド | getLanguges |
%ZEN.Portal.assistedText | メソッド | ServerCallOnUpdateDataServer |
%ZEN.Template.AddInWizard.Template | メソッド | ZStripW |
%ZEN.Template.WebServiceWizard | メソッド | ZStripW |
%iKnow.Classification.Builder | メソッド | %AddTerm、%GetCategoryPosition、%GetTermPosition |
— | プロパティ | Categories、Terms |
%iKnow.Classification.Definition.ClassificationMethod | プロパティ | localTermMetric |
%iKnow.Classification.Definition.Term | プロパティ | value |
%iKnow.Classification.IKnowBuilder | メソッド | %GetCategoryFilters |
%iKnow.Classification.LinearBuilder | プロパティ | CategoryGlobalTermWeights、CategoryLocalTermMetric、CategoryLocalTermWeights、CategoryNormalization |
%iKnow.DeepSee.UI.Analysis.Entities | メソッド | AnalyzeString、GetChartData、GetLabelX、RemoveEntity、UpdateCharts、getChartDataClient、getLabelXClient、onChangeMetricClient |
— | プロパティ | termIndex |
%iKnow.ont.Matcher | メソッド | GetATUI |
Config.ComPorts | パラメータ | EMSLISTQUERY |
Config.CommonMapMethods | パラメータ | EMSLISTQUERY |
Config.CommonMethods | パラメータ | EMSCHANGEBIT、PROPERTIESMAYBEINCPF |
Config.CommonMultipleMethods | パラメータ | EMSLISTQUERY |
Config.Databases | パラメータ | EMSLISTQUERY |
Config.Debug | パラメータ | EMSLISTQUERY |
Config.DeviceSubTypes | パラメータ | EMSLISTQUERY |
Config.Devices | パラメータ | EMSLISTQUERY |
Config.ECPServers | パラメータ | EMSLISTQUERY |
Config.LicenseServers | パラメータ | EMSLISTQUERY |
Config.MapGlobals | パラメータ | EMSLISTQUERY |
Config.MapPackages | パラメータ | EMSLISTQUERY |
Config.MapRoutines | パラメータ | EMSLISTQUERY |
Config.MapShadows | パラメータ | EMSLISTQUERY |
Config.Mirrors | プロパティ | ACKRequirement、AgentContactRequiredForTakeover、TroubleTimeout |
Config.Namespaces | パラメータ | EMSLISTQUERY |
Config.Shadows | パラメータ | EMSLISTQUERY |
Config.SqlSysDatatypes | パラメータ | EMSLISTQUERY |
Config.SqlUserDatatypes | パラメータ | EMSLISTQUERY |
Ens.Enterprise.Portal.MonitorStatus | メソッド | DrawMsgBankLinks、showDetails |
Ens.Util.Documentation | メソッド | BuildVMSFileURL |
SYS.Monitor.Health.SensorObject | プロパティ | MaxValue |
Security.Applications | プロパティ | HyperEvent |
メソッド返り値の変更
今回のバージョンの Caché では、以下のメソッド返り値が変更されました。
-
%iKnow.Utils.MaintenanceAPI — BlacklistContainsElement
-
%iKnow.Utils.MaintenanceQAPI — BlacklistContainsElement
-
%iKnow.Utils.MaintenanceWSAPI — BlacklistContainsElement
-
SYS.Agent — VerifyConnection
メソッド・シグニチャの変更
今回のバージョンの Caché では、以下のメソッドのシグニチャが変更されました。
クラス名 | メソッド名 |
---|---|
%CSP.UI.Component.ApplicationRoles | AssignRole、RemoveAllRoles、RemoveRole |
%CSP.UI.Component.RoleMemberTab | AssignRoles、RemoveAllRoles、RemoveRole、doRemoveAllRoles、doRemoveRole |
%CSP.UI.Component.SQLPrivileges | AssignPrivs、RemoveAllPrivs、RemovePriv |
%CSP.UI.Component.SelectBoxUtils | DrawArrows、DrawAvailableList、DrawSelectList |
%CSP.UI.Component.UserRoles | AssignRoles、RemoveAllRoles、RemoveRole |
%CSP.UI.Portal.Applications.PrivRoutine | AddRoutine、RemoveRoutine |
%CSP.UI.Portal.Applications.Utils | Delete |
%CSP.UI.Portal.Applications.Web | BuildAutheArray、CopyApp |
%CSP.UI.Portal.Audit.EventsTemplate | ChangeStatus |
%CSP.UI.Portal.Audit.UserEvents | Delete |
%CSP.UI.Portal.Config.Advanced | SaveData |
%CSP.UI.Portal.Config.AdvancedList | DeleteData |
%CSP.UI.Portal.Config.ValueEditor | SaveData |
%CSP.UI.Portal.Database | changeJournal、changeReadOnly |
%CSP.UI.Portal.Dialog.DatabaseDelete | DisableEnsNamespace |
%CSP.UI.Portal.Dialog.DatabaseWizard | validateSize |
%CSP.UI.Portal.Dialog.EncAddAdmin | SaveData |
%CSP.UI.Portal.Dialog.LicenseActivate | Activate、DrawCurrent、PrepareActivate |
%CSP.UI.Portal.Dialog.RemoteDatabase | CheckDBName |
%CSP.UI.Portal.Dialog.SQLView | SaveData |
%CSP.UI.Portal.Dialog.ShadowDBMapping | MapShadowExists |
%CSP.UI.Portal.Domains | Delete |
%CSP.UI.Portal.ECPDataServers | DeleteServer |
%CSP.UI.Portal.EncryptionDatabase | SetDefaultKey |
%CSP.UI.Portal.EncryptionManage | doAdd |
%CSP.UI.Portal.License.Utils | DrawFile、DrawLicense、GetLicenseInfo |
%CSP.UI.Portal.LicenseServers | DeleteData |
%CSP.UI.Portal.NLS | CopyNow、DeleteNow、GetLocaleDesc、GetLocaleDescription、ReloadDefault、SaveNow |
%CSP.UI.Portal.Namespace | doNew |
%CSP.UI.Portal.PhoneProviders | Delete |
%CSP.UI.Portal.Resources | Delete |
%CSP.UI.Portal.Roles | Delete |
%CSP.UI.Portal.SQL.Home | SaveFilter、updateTreeItems |
%CSP.UI.Portal.Shadow | DeleteMap |
%CSP.UI.Portal.Shadows | DeleteData |
%CSP.UI.Portal.Users | Delete |
%CSP.UI.Portal.iKnow.Configurations | doClose、doDelete、doSave |
%CSP.UI.Portal.iKnow.Dialog.AddDomainConfig | SaveConfig |
%CSP.UI.System.ExpResultPage | CopyMapsFrom |
%DeepSee.Component.pivotTable | GetCurrentQueryText |
%DeepSee.PMML.Model.NaiveBayes | GetLikelihoods |
%DeepSee.Report.UI.QueryBasedDSS | updateGroupings |
%DeepSee.Report.UI.schemaEditPanel | addDBItemFromDrag、autopopulateDBItem、makeNode |
%DeepSee.TermList | %ImportCSV、%WriteCSVRecord |
%DeepSee.extensions.modelling.Processor | applyModel、applyOperation |
%Dictionary.ClassDefinition | %LockId |
%Dictionary.CompiledClass | %LockId |
%Dictionary.CompiledConstraint | %LockId |
%Dictionary.CompiledConstraintMethod | %LockId |
%Dictionary.CompiledForeignKey | %LockId |
%Dictionary.CompiledIndex | %LockId |
%Dictionary.CompiledIndexMethod | %LockId |
%Dictionary.CompiledIndexProperty | %LockId |
%Dictionary.CompiledInstanceVar | %LockId |
%Dictionary.CompiledMethod | %LockId |
%Dictionary.CompiledParameter | %LockId |
%Dictionary.CompiledProjection | %LockId |
%Dictionary.CompiledProperty | %LockId |
%Dictionary.CompiledPropertyMethod | %LockId |
%Dictionary.CompiledPropertyUDLText | %LockId |
%Dictionary.CompiledQuery | %LockId |
%Dictionary.CompiledQueryMethod | %LockId |
%Dictionary.CompiledStorage | %LockId |
%Dictionary.CompiledStorageData | %LockId |
%Dictionary.CompiledStorageDataValue | %LockId |
%Dictionary.CompiledStorageIndex | %LockId |
%Dictionary.CompiledStorageProperty | %LockId |
%Dictionary.CompiledStorageSQLMap | %LockId |
%Dictionary.CompiledStorageSQLMapData | %LockId |
%Dictionary.CompiledStorageSQLMapRowIdSpec | %LockId |
%Dictionary.CompiledStorageSQLMapSub | %LockId |
%Dictionary.CompiledStorageSQLMapSubAccessvar | %LockId |
%Dictionary.CompiledStorageSQLMapSubInvalidcondition | %LockId |
%Dictionary.CompiledTrigger | %LockId |
%Dictionary.CompiledUDLText | %LockId |
%Dictionary.CompiledXData | %LockId |
%Dictionary.ForeignKeyDefinition | %LockId |
%Dictionary.IndexDefinition | %LockId |
%Dictionary.MethodDefinition | %LockId |
%Dictionary.ParameterDefinition | %LockId |
%Dictionary.ProjectionDefinition | %LockId |
%Dictionary.PropertyDefinition | %LockId |
%Dictionary.PropertyUDLTextDefinition | %LockId |
%Dictionary.QueryDefinition | %LockId |
%Dictionary.StorageDataDefinition | %LockId |
%Dictionary.StorageDataValueDefinition | %LockId |
%Dictionary.StorageDefinition | %LockId |
%Dictionary.StorageIndexDefinition | %LockId |
%Dictionary.StoragePropertyDefinition | %LockId |
%Dictionary.StorageSQLMapDataDefinition | %LockId |
%Dictionary.StorageSQLMapDefinition | %LockId |
%Dictionary.StorageSQLMapRowIdSpecDefinition | %LockId |
%Dictionary.StorageSQLMapSubAccessvarDefinition | %LockId |
%Dictionary.StorageSQLMapSubDefinition | %LockId |
%Dictionary.StorageSQLMapSubInvalidconditionDefinition | %LockId |
%Dictionary.TriggerDefinition | %LockId |
%Dictionary.UDLTextDefinition | %LockId |
%Dictionary.XDataDefinition | %LockId |
%Library.CacheSQLStorage | %LockId |
%Library.EnsembleMgr | EnableNamespace、createMappings |
%Library.FunctionalIndex | SegmentFinalize、SegmentInitialize、SegmentInsert |
%Library.GlobalEdit | GetGlobalSizeBySubscript |
%Library.GlobalStreamAdaptor | Read |
%Library.ListOfDataTypes | DisplayToLogical、LogicalToDisplay |
%Library.Persistent | %BuildIndices、%LockId |
%Library.RoutineMgr | getPackageList |
%Net.Remote.Proxy | %Constructor |
%SOAP.WST.BinarySecret | Create |
%SQL.CustomResultSet | %OnNew |
%SYSTEM.Encryption | MD5HashStream、SHA1HashStream、SHAHashStream |
%SYSTEM.SQL | SetSQLStats、SetSQLStatsJob |
%SYSTEM.Util | GetSessionId |
%Stream.TmpCharacter | Read |
%Studio.General | Execute |
%Studio.Project | InstallFromGbl |
%Studio.SourceControl.Change | DisplayUncommitted |
%UMLS.Utils | GetChildrenAsRS |
%ZEN.Auxiliary.jsonSQLProvider | %WriteJSONStreamFromSQL |
%ZEN.Component.dateText | showDateSelector |
%ZEN.Component.tablePane | executeQuery |
%ZEN.Report.Display.call | %DrawToHTML |
%ZEN.Report.Display.callsvg | %DrawToHTML |
%ZEN.Report.Display.category | %DrawToHTML |
%ZEN.Report.Display.class | %DrawToHTML |
%ZEN.Report.Display.cssinclude | %DrawToHTML |
%ZEN.Report.Display.fo | %DrawToHTML |
%ZEN.Report.Display.group | %DrawToHTML |
%ZEN.Report.Display.html | %DrawToHTML |
%ZEN.Report.Display.img | %DrawToHTML |
%ZEN.Report.Display.init | %DrawToHTML |
%ZEN.Report.Display.inline | %DrawToHTML |
%ZEN.Report.Display.line | %DrawToHTML |
%ZEN.Report.Display.list | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.masterreference | %DrawToHTML |
%ZEN.Report.Display.node | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.p | %DrawToHTML |
%ZEN.Report.Display.pagebreak | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.pageendsidebar | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.pagefooter | %DrawToHTML |
%ZEN.Report.Display.pageheader | %DrawToHTML |
%ZEN.Report.Display.pagemaster | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.pagestartsidebar | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.report | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.section | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.table | %DisplayTableByRowsFO |
%ZEN.Report.Display.write | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.Display.xslinclude | %DrawToHTML |
%ZEN.Report.Display.xslt | %DrawToHTML、%DrawToXSLFO |
%ZEN.Report.RenderServer | GetState |
%ZEN.Report.SplitAndMerge | %DisplayPDF |
%ZEN.SVGComponent.treeMapChart | plotItems |
%iFind.Find.Basic | ResolveCompCombArray、ResolveStemmedCombArray |
%iKnow.Classification.Builder | %GenerateClassifier、%LoadFromDefinition、%OnGenerateClassifier、%PopulateTerms |
%iKnow.Classification.IKnowBuilder | %TestClassifier |
%iKnow.Filters.ContainsEntityFilter | %OnNew |
%iKnow.Filters.ExternalIdFilter | %OnNew |
%iKnow.Filters.GroupFilter | %OnNew |
%iKnow.Filters.RandomFilter | %OnNew |
%iKnow.Filters.SourceIdFilter | %OnNew |
%iKnow.Matching.DictionaryAPI | CreateDictionaryItem、CreateDictionaryItemAndTerm |
%iKnow.Matching.DictionaryQAPI | CreateDictionaryItem、CreateDictionaryItemAndTerm |
%iKnow.Queries.SourceAPI | GetSummaryForText |
%iKnow.Queries.SourceWSAPI | GetSummaryForText |
%iKnow.UI.AbstractSourceViewer | ProcessInput |
Ens.DataTransformDTL | Transform |
Ens.Deployment.Utils | GetItemContentsByItemNumber |
Ens.Director | IsProductionRunning |
##class(%Library.%File).ParentDirectory() の動作の変更
今回のリリースでは、##class(%Library.%File).ParentDirectory() が変更され、それにディレクトリ名ではなくファイル名を指定すると “” が返されるようになりました。 以前は、呼び出し元の親ディレクトリが返され、混乱を招きやすくなっていました。
%Net.HttpRequest でのすべてのタイプに対する charset 値の処理
%Net.HttpRequestOpens in a new tab クラスでは、Content-Type が “text/” ではない場合でも HTTP 応答の CharSet 値が処理されるようになりました。これにより、“utf-8” 文字セットが指定されている場合であってもタイプ “application/json” を適切にデコードできます。また、RFC2616 によれば、テキスト・コンテンツのみに文字セットを適用するという制約はありません。
これは、動作における小さな変更ですが、標準に従って修正されました。従来の動作に戻すには、ReadRawMode プロパティを 1 に設定します。
エラー後のタスクの続行の可能化
今回のリリースでは、タスクに SuspendOnError という新しいプロパティがあります。以前は、すべてのタスクが、エラー・ステータスが返されると中断されていました。現在は、既定でタスクはエラー後に再スケジュールされ、続行されるようになりました。従来の動作に戻すには、管理ポータルまたは ^TASKMGR のいずれかで SuspendOnError に “Yes” を設定します。
$SYSTEM.Lock.ReturnCode() の新しい戻り値
この変更により、$SYSTEM.Lock.ReturnCode() メソッドに新しい戻りコードが追加されました。すでにロックがエスカレートされていることを示す値の 4 を返すことができるようになりました。2 の値がロック・コマンドによってロック・エスカレーションが開始されたことを示すのに対し、この新しい値は、前のロック・コマンドでロック・ノードがエスカレート済みであることを示します。
クラス・コンパイラの変更
今回のバージョンの Caché では、以前のリリースと同様、引き続きクラス・コンパイラの向上を図っていきます。このセクションでは、アプリケーション変更を必要とする可能性のある変更について詳述します。
シリアル・クラスでの再帰的プロパティ・タイプの明示的不正
シリアル・クラスのプロパティのタイプは再帰的にすることはできません。つまり、型クラスをコンテナ・クラスにしたり、そのコンテナ・クラスのプライマリ・スーパー・クラスまたはサブクラスにすることはできません。例えば、タイプが Sample.Address であるプロパティを Sample.Address で定義することは無効です。
このモデルは以前は実行時に機能していなかったため、この変更により大きな問題は発生しません。 Caché では、再帰的シリアル・タイプの SQL プロジェクションをサポートしたことはありません。以前のバージョンではそのようなクラスが正常にコンパイルされていましたが、この変更により、コンパイル時に新しいエラーが報告されるようになりました。
DataType クラスでの最適化されたメソッド呼び出しの処理の修正
今回のリリースでは、ターゲット・メソッドがローカル・クラスと宣言されたデータ型クラスの両方で定義されている場合に、“DO ..otherMethod()” 形式のメソッド呼び出しの解決で発生するエラーが修正されました。
大まかに以下のように定義されているデータ型クラスを考えてみましょう。
Class User.DataType Extends %String { Parameter PARAM = "HELLO"; ClassMethod someMethod() { Write ..#PARAM,! Do ..otherMethod() } ClassMethod otherMethod() { Write ..#PARAM,! } }
これには、“HELLO” の既定値で定義されているパラメータと、単にこのパラメータ値を書き出す otherMethod を呼び出すクラスメソッド (someMethod) があります。
ここで、このデータ型クラスを使用する標準クラスを考えてみましょう。
Class User.User Extends %RegisteredObject { Property Prop As DataType(PARAM = "MYVAL"); }
以前のリリースでは、以下の文のシーケンスによって
SET A = ##class(User).%New() DO A.PropsomeMethod()
以下のものが表示されます。
MYVAL HELLO
これは誤りです。それは、これは MYVAL を 2 回書き出すはずであるからです。ただし、“Do ..otherMethod()” の正規化は、ローカルに宣言されている PropsomeMethod メンバ・メソッドを呼び出すのではなく、User.DataType クラス自体を呼び出していました。
今回のリリースでは、この呼び出しのコンパイルは、適切にローカル・メンバ・メソッドを呼び出すようになっており、コンパイル済みコードを実行すると、本来あるべきとおりに MYVAL が 2 回出力されます。これにより、同じクラス・コンテキストにあるため、クラスメソッド・メンバ・メソッドは、異なるプライベート・クラス・メソッドを呼び出すことも可能になります。ただし、これは、現在ではエラーを生成します。
既存の動作が必要とされることは少ないですが、ローカル・メソッドではなくメンバ・クラスのメソッドを呼び出すことが必要なこともあります。これを行うには、“Do ..otherMethod()” を “Do ##class(User.DataType).otherMethod()” に置き換えると、従来と同様に動作します。
作業キュー処理の簡素化
今回のリリースでは、クラス・コンパイラが SignalAll 関数を使用してそのワーカ・ジョブに信号を送信することはなくなりました。それは、使用率の高いシステムでは、一部のワーカ・ジョブは現在のコンパイルに関与していない可能性があるためです。今回のリリースでは、同じ理由で StopWorkers 呼び出しも削除されています。
言語バインディングの変更
Caché の Objective C バインディングでの新しいランタイムの使用
Objective-C の新しいランタイムでは、Caché での以下の変更が必要となっています。
ISCConnection を作成する新しい方法は以下のとおりです。
ISCConnection* conn = [ISCConnection connectionTo:@"127.0.0.1[1972]:SAMPLES" user:@"sys" password:@"system"];
および、安全な接続のためには以下のようにします。
ISCConnection* conn = [ISCConnection connectionTo:@"127.0.0.1[1972]:SAMPLES" principal:@"principal" level:1];
ISCDatabase を作成する新しい方法は以下のとおりです。
ISCDatabase* database = [ISCDatabase databaseWithConnection:conn];
ここで、conn は、前に確立された接続です。
接続プールを設定するための新しいメソッドは以下のとおりです。
ISCConnectionPool* pool = [ISCConnectionPool pool];
CacheProvider のシステム・クラスのコード生成の削除
以前のリリースでは、.NET 用の生成されたプロキシ・クラスには、実際はクライアントからの使用を意図していない多数の API が含まれていました (例えば、ODBCToLogical および LogicalToODBC の変換)。この変更により、生成されたコードからこれらの API を削除する方法が追加されました。dotnet_generator には、-skip-system-apis (true|false) オプションが含まれるようになりました。これを true (既定値) に設定するとユーザの API のみが生成され、それにより、生成されたコードは以前の 3 分の 1 の大きさになります。
オブジェクト・プロパティの型指定コレクションのサポート
今回のリリースでは、Caché Objectscript オブジェクトのグループを、型のコレクションとして投影できます。例えば、型 T の %Library.ListOfObjects として定義されたクラス・プロパティは、CacheListOfObjects<T> として投影されます。同様に、T の %Library.ArrayOfObjects は CacheArrayOfObjects<T> として投影されます。この変更により、コレクションの投影に関連する大部分のキャストが不要になります。
この変更により、ListOfObjects.OpenAllObjects() の再帰バージョンも非推奨になりました。それは、現在は、生成されたコードには CacheListOfObjects<T> または CacheArrayOfObjects<T> が必要であるのに対し、この呼び出しによって、強制的にクライアントがサーバ・オブジェクトの CacheListOfObects または CacheArrayOfObjects の汎用バージョン (テンプレートではない) をインスタンス化する可能性があるためです。
この変更の 1 つの制限は、コレクションが、その要素の型が不明であるコンテキストでコレクションがインスタンス化される場合 (例えば、コレクションがメソッドから返される場合)、プロキシ・クラスは CacheListOfObects または CacheArrayOfObjects (テンプレートなし) になることです。後で、要素型が既知でかつ予期されているコンテキストで同じオブジェクトが使用される場合、その時点までに “誤った” プロキシ・オブジェクトが既に使用されていて自動的に置換できないため、例外が発生します。そのような場合は、非常にまれです。
CacheProvider による For Open() および OpenId() のオーバーロードされたメソッドの追加
以下のようなコードがある場合、
Prop = obj.Property ... Prop.Close()
これは、プロパティをアンスウィズルすることを意図していましたが、現在では、サーバ上の値が null でなくても後続の obj.Property の呼び出しによって null 値が返されます。これは、obj がプロパティを所有しており、obj が閉じるときにそのプロパティが自動的に閉じるためです。 これを実現する適切な方法は、新しい UnswizzleProperty(<PropertyName>) メソッドの呼び出しを使用することです。
CacheADOConnection をパブリックにして ADO.NET を直接使用
CacheConnection は、すべての ADO.Net 機能を提供する CacheADOConnection クラスから継承します。 CacheConnection で、アプリケーションは同じ接続を介して ADO と DotNet Object バインディングの両方を使用できます。 これは多くのアプリケーションにとって役立ちますが、サーバへの追加のメッセージおよびプロバイダ内の内部オブジェクトの作成という点ではオーバーヘッドが追加されます。
XEP および Entity Framework 接続はそれぞれ、CacheADOConnection とそれが提供する機能にのみ依存しています。 DbConnection は、ADO.Net の DbFactory 接続に使用される一般的な方法であり、CacheADOConnection 内で完全にサポートされています。 これらの汎用 ADO API を使用する場合、CacheConnection オブジェクトによって別の値は追加されず、オーバーヘッドのみが追加されます。
この変更により、CacheConnection は引き続き従来どおり機能しますが、ADO アプリケーションは、CacheProvider のオブジェクト・バインディング・サイドを使用しない場合に CacheADOConnection を直接使用できます。 さらに、CacheFactory は少ないオーバーヘッドで CacheADOConnection オブジェクトを返します。 ADO 機能は引き続き、CacheConnection と CacheADOConnection のいずれでも機能しますが、ユーザがそれらのアプリケーションを変更する必要はありません。
いくつかの CacheConection のパブリック API は CacheADOConnection には存在しません。 必要な ADO.Net API はすべて CacheADOConnection 内に含まれていますが、アプリケーション・ライターは CacheProvider のオブジェクト・サイドによって提供される混合 API を使用した場合もあります。 その場合、引き続き、以前どおりに CacheConnection クラスを使用できます。
SQL の変更
$LIST コンテンツが含まれているストリームの $LIST の OID の置換
今回のバージョンから、SQL を介してストリーム・フィールドに $LIST 値を格納できるようになりました。この変更により、バイナリ・データが $LIST 値に似ていた (つまり、$LISTVALID(value) が True であった) 場合にバイナリ・ストリーム・フィールドへのバイナリ・データの挿入が失敗する可能性があった問題も修正されました。
以前のバージョンでは、$LIST 値がストリーム値として挿入または更新された場合、Caché では $LIST 値がターゲット・ストリームにコピーされた別のストリームの OID であると想定されていました。 これは、既定では非外部テーブルのストリーム・フィールドを含む select クエリでは、そのストリーム・オブジェクトの OID が返されるためです。 別のストリーム・フィールドから選択した値を使用してストリーム・フィールドの値に挿入するか、またはストリーム・フィールドの値を更新する必要があるアプリケーションは、そのストリーム OID を開いてストリーム値をコピーするのみでした。
現在は、$LIST 値である値を持つストリーム・フィールドの SQL INSERT または UPDATE は、$LIST 値を、新しいストリームの値のソース・ストリームの OID として処理しなくなりました。 ソース・ストリームを開き、ソース・ストリームの OREF の値を使用してフィールドを挿入または更新する必要があります。これは、アプリケーションがストリーム・ソースの OID を持つストリーム・フィールドを挿入または更新しようとする場合の下位互換性を提供します。 互換性の問題は、ストリーム値を模倣したバイナリ・データを挿入したり、$LIST データをストリームに格納するために必ず発生します。
FOR SOME 述語でのテーブルを囲む括弧の必要性
ほとんど使用されない FOR SOME 述語の構文が変更され、Caché SQL 構文でのあいまいさが排除されました。以前は、述語の構文は次のとおりでした。
FOR SOME <tables> (<search condition> ...)
現在は、次のように表す必要があります。
FOR SOME (<tables>) (<search condition> ...)
従来の FOR SOME <tables> 構文を使用しているアプリケーションは、括弧を追加する必要があります。
これは、よく使用される FOR SOME %ELEMENT 構文には何の影響も与えません。
新しい SQL システム特権
このバージョンでは、ネームスペース・レベルごとにユーザまたはロールに割り当てることができる新しい一般的な SQL 特権が 4 つあります。
-
%NOCHECK — ユーザは %NOCHECK を指定して INSERT、UPDATE または DELETE コマンドを実行できるようになります。
-
%NOTRIGGER — ユーザは %NOTRIGGER を指定して、INSERT、UPDATE または DELETE コマンドを実行できるようになります。
-
%NOINDEX — ユーザは %NOINDEX を指定して INSERT、UPDATE または DELETE コマンドを実行できるようになります。
-
%NOLOCK — ユーザは %NOLOCK を指定して INSERT、UPDATE または DELETE コマンドを実行できるようになります。
これらの特権は、INSERT、UPDATE、または DELETE 文の制限節でのそれぞれのキーワードの使用にのみ適用されます。 述語条件の前にある %NOINDEX の使用には適用されません。他の SQL 特権と同様に、これは ODBC、JDBC、%SQL.StatementOpens in a new tab、および %Library.ResultSetOpens in a new tab を介してのみ適用されます。 文を準備するときに制限節を使用するには、適切な特権を持っている必要があります。
TRUNCATE TABLE <tablename> は、%NOTRIGGER 動作によりテーブルからの行の削除を実行するため、TRUNCATE TABLE <tablename> の実行にも %NOTRIGGER 特権が必要になりました。
この変更により、現在のアプリケーションで下位互換性の問題が発生する可能性がありますが、これらの制限節は論理的に壊れたデータを生成することがあるため、インターシステムズではこの機能を進化させてお客様のデータの整合性の保護を強化することを決定しました。
<Column>=<Constant> 条件の複数の JOIN があるクエリの修正
今回のリリースには、以下のようなクエリに対する修正が含まれています。
SELECT t . test_code FROM test . person p , test . test_result t WHERE p . hospital_id = ? AND p . person_id = ? AND t . hospital_id = p . hospital_id AND t . person_id = p . person_id
ここには、以下があります。
-
2 つ以上の結合条件を持つ 2 つのテーブル間の結合があります。
-
さらに、そのような結合ごとに、結合の列の 1 つに <column>=<constant> 条件もあります。
従来のリリースでは、SQL パーサによって、そのような要求ごとに不正なクエリ・プランが生成されました。そのエラーは、今回のリリースで修正されました。
タイムスタンプを使用したクエリ処理の修正
今回のリリースより前は、以下のようなクエリを実行するアプリケーションの場合:
-
“TimeStampField > CURRENT_TIMESTAMP” のような WHERE 節にフィルタが含まれている。
-
TimeStampField が一般的な %Library.TimeStampOpens in a new tab 値ではない。
-
TimeStampField のクラス・インスタンスにより、LogicalToTimeStamp および TimeStampToLogical メソッドが実装され、その論理形式が %TimeStampOpens in a new tab 論理形式に変換される。
クエリから不正な結果が得られることがありました。このエラーは、今回のリリースで修正されました。
クエリ・プランの変更
今回のリリースでは、いくつかの条件が他の条件を暗黙的に示す場合を考慮した向上した選択機能により、クエリ・プロセッサがより正確なプランを作成するようになりました。この典型的な例は、次のようなクエリです。
SELECT * FROM T1, T2 WHERE T1.k = T2.k AND T1.k > 5
この場合、オプティマイザによって T2.k > 5 も真であることが導出されます。また、条件が T1.k > 5、T1.k = T2.k、T2.k >5 の順序でテストされる場合、最後の条件は冗長であり、選択がさらに追加されることはありません。同様に、条件のテストの順序が、T2.k > 5、T1.k = T2.k、T1.k > 5 である場合、似たような状況になります。ただし、条件のテストの順序が T1.k > 5、T2.k > 5、T1.k=T2.k である場合、最後の条件はテストする必要はあるものの、他のテスト順序の場合よりも追加される選択が少なくなります。以前のリリースでは、この最後のケースで選択を適切に処理する方法がありませんでした。
この変更の結果は、プランの変更が多少一般的になり、大部分は向上しますが、劣化するものもあります。
SQL 予約語の更新
以下の語は、以前のリリースの Caché SQL で予約されていましたが、$SYSTEM.SQL.IsReservedWord() によってそのように報告されませんでした。
%CLASSNAME, %ID, %KEY, %MINUS, %MVR, %ODBCIN, %PLUS, %RUNTIMEIN, %RUNTIMEOUT, %SQLSTRING, %SQLUPPER, %TABLENAME, %TRUNCATE, %VALUE, %VID
今回のリリースでは、それらがリストに追加され、予約語としての CATALOG が削除されています。
DELETE %NOINDEX の変更
以前のリリースでは、SQL 指示文 DELETE %NOINDEX は常に空命令でした。今回のリリースから、削除された行に定義されたインデックス・エントリは削除されなくなりした。
%SYS.PTools.UtilResults の変更
以前は、管理ポータルの [インデックス分析] ページでは、ラジオ・ボタンをクリックするたびに、異なるオプションが再計算されました。 今後は、テーブルに 4 つのすべてのオプションに対する結果が保持でき、新しい SQL 文が収集された場合にのみデータがクリアされます。 オプションを初めてクリックしたときはシステムによってデータが生成されますが、それ以降は単にそれが再表示されます。
アプリケーションがデータをクエリしている場合、新しいプロパティ OptionName の値を設定することで返される結果を制限できるようになりました。 設定可能な 4 つの値は次のとおりです。
-
“IU” — インデックス使用
-
“TS” — テーブル・スキャン
-
“TI” — テーブル・インデックス
-
“JI” — 結合インデックス
接続が指定された場合のチェックの強化
リンクされたテーブルがクラスの一部として定義されている場合、SQL プロセッサによって、テーブルへの接続の確立に必要なすべての値が指定されていることもチェックされるようになりました。これに該当しない場合、SQL エラー -162 (“SQL Connection is not defined”) が生成されます。
ロケールおよび入出力変換テーブルの変更
スペイン語ロケールの既定の照合における変更
Spanish4 が、ローカル配列および新規データベースのスペイン語ロケール (espw、esp8、esi8、esw8) の現在の既定の照合になりました。この新しい照合では、大文字と小文字が別々に順序付けされており、文字は以下の順序に従います。
a, á, à, b, c, ç, d, e, é, è, f, g, h, i, í, j, k, l m, n, ñ, o, ó, ò, p, q, r, s, t, u, ú, ü, v, w, x, y, z
以前のスペイン語照合テーブルも使用できます。以前の既存のデータベースの照合は変更されていません。
新しいマルタ語照合の作成
マルタ語 Unicode ロケール (mltw) および照合 (Maltese1) は、今回のリリースで使用可能になりました。この照合の特性は以下のとおりです。
-
大文字小文字は別々に順序付けされ、すべての大文字はすべての小文字より前にあります。
-
主要な順序付けは以下のとおりです (小文字の場合。大文字も同様です)。
a b ċ c d e f ġ g għ h ħ i ie j k l m n o p q r s t u v w x z ż
-
上記のドット付きの文字 (c、g、および z) は、ドットのないバージョンと同等ですが、同じものを除いてそれらはすべて、ドットのない同じ文字の前に照合されます。
-
“għ” は、“g” と “h” の間の 1 つの文字として照合されます。
-
“ie” は、“i” と “j” の間の 1 つの文字として照合されます。
-
“ħ” は “h” と同等ですが、後で照合されます。
マルタ語アルファベットにはありませんが、ラテン文字 “c” と “y” は、英語でのそれぞれの位置で照合されます。マルタ語にない他のすべてのアクセント記号付き文字 (“á”、“é”、“ã” など) はアルファベットの後に照合されます (Caché 標準と同じ)。
新しい照合 Maltese2 マルタ語 Unicode ロケールで使用可能です。これには、Maltese1 と同じエンコードがありますが、合字 “għ” および “ie” は含まれていません。
Unicode ↔ CP437、CP850、および CP852 の新しい入出力変換テーブル
今回のリリースには、Unicode とロケール CP437、CP850 および CP852 との間の新しい入出力変換テーブルが含まれています。これらのテーブルは、8 ビットバージョンが Latin1 または Latin2 を基盤としている Unicode ロケールに追加されました。 具体的には、新しいテーブルは、以下の Unicode ロケールにあります。
-
csyw – チェコ語、チェコ共和国
-
danw – デンマーク語、デンマーク
-
deuw – ドイツ語、ドイツ
-
engw – 英語、英国
-
enuw – 英語、米国
-
espw – スペイン語、スペイン
-
finw – フィンランド語、フィンランド
-
fraw – フランス語、フランス
-
hunw – ハンガリー語、ハンガリー
-
itaw – イタリア語、イタリア
-
nldw – オランダ語、オランダ
-
plkw – ポーランド語、ポーランド
-
ptbw – ポルトガル語、ブラジル
いくつかのロケール用のアップグレードされた照合
以下の 8 ビット・ロケールの既定の照合は、以前のバージョンにおける小さな問題 (スペイン語の “ll” およびドイツ語の “ss” のように 1 つの文字として照合されるいくつかの文字シーケンスを考慮できないなど) を修正する新しいバージョンにアップグレードされました。
-
csw8:Czech2/CP1250 → Czech3
-
huw8:Hungarian1/CP1250 →Hungarian2
-
esw8:Spanish2/CP1252 → Spanish3
-
esi8:Spanish2/Latin9 → Spanish3
German4 ロケールの削除
German4 ロケールは、German3 と機能的に同等であると判明したため、今回のリリースでシステムから削除されました。
ロシア語ロケールの磁気テープ変換テーブルの変更
ロシア語 Unicode ロケール (rusw) の磁気テープ・デバイス用の既定の変換が、RAW から UTF8 に変更されました。これにより、テープへのバックアップのラベルに、さらに修正することなくキリル文字を含めることが可能になりました。
Latin9 ↔ Unicode の変換テーブルの更新
Latin9 と Unicode エンコード (UnicodeBig、UnicodeLittle、および UTF8) の 1 つとの間の変換を行うテーブルで、誤って $CHAR(128) から U+20AC (ユーロ記号) にマップされていました。このマッピングは、Windows CP テーブルの多くで使用されていますが、ユーロ記号が $CHAR(164) である Latin9 では使用されていません。これらの Latin9 変換テーブルでは、$CHAR(128) は変更されずに通過します。
新しい JSON 変換テーブルの追加
今回のリリースでは、2 つの新しい NLS 変換、JSON と JSONML が追加されています。それらは、それぞれ JS と JSML に類似していますが、出力側で以下の違いがあります。
-
コード 0 ~ 7、11 および 14 ~ 31 を持つ文字は \uXXXX としてエスケープされます。
-
コード 39 および 47 を持つ文字は、変更されずに通過します。
Unicode LINE SEPARATOR および PARAGRAPH SEPARATOR の処理の更新
Unicode システムでは、例えば、$ZCONVERT で使用される場合、JavaScript 変換 (JS、JSON、JSML、および JSONML) の 1 つを通過するときに、文字 LINE SEPARATOR ($CHAR(8232) = U+2028) および PARAGRAPH SEPARATOR ($CHAR(8233) = U+2029) はそれぞれ "\u2028" および "\u2029" としてエスケープされます。
iKnow の変更
コード化されたディクショナリ用語の修正
ディクショナリ用語が複数の要素で構成されており、それらに (複合用語を追加するための形式の “コード化された” 記述の使用を介して) 形式要素と非形式要素の両方が含まれている場合、ディクショナリが最適化されていると、内部データ構造にディクショナリ用語が適切に保存されませんでした。これにより、形式部分と非形式部分が別々に照合されることになり、同じ CRC またはパス上の同じ用語が別個の一致になる可能性がありました。
高度な “コード化” 記述機能を使用して混合する用語 (形式ベースの要素と非形式ベースの要素の両方から成る) を挿入した場合、この修正を有効にするには、これらのディクショナリ用語を再作成する必要があります。
(以前は実験的であった) PMML モデリングの変更
2014.1 の実験的機能としてモデル構築機能が追加されました。これを活用するアプリケーションを構築したユーザは、PMML モデルを生成するためのいくつかのヘルパー・メソッドがビルダ・クラスから PMML モデル・クラスに移動したことを見つけることになります。さらに、
-
多様な演算子によって “途中で行われていた” PMML の生成が、適切な場所で行われるようになり、実行されるすべての演算子を表す PMML ファイルになります。
-
モデリング・シーケンスの一部として任意のコードを実行する “Call” 演算子が存在するようになりました。
-
“TypeColumn” プロパティが Attributes 構成要素に追加され、データ型の属性ごとの指定が可能になりました。
-
Sequence 処理の一部として新しい行をインスタンス化する場合、PMML モデルは明示的にすべての属性を 0 に設定することはなくなりますが、初期値の入力は InitialExpressions に依存します (%IntegerOpens in a new tab および TableGenerator 処理の %DoubleOpens in a new tab 列の場合は 0)。
-
新しい “InsertOnly” プロパティが Sequence 構成要素に存在し、既にデータが含まれているテーブルに追加できます。つまり、データの一部が iKnow ドメインから、他の部分が他のソース (メタデータ) から直接取得できる場合のように、個別の Sequence 処理を使用して、同じデータ・セットの別々の列に入力できます。
Web サービスと SOAP の変更
%Net.HttpRequest In %XML.Sax.Parser の既定のポート値の明示的な設定
今回のリリースでは、%Net.HttpRequestOpens in a new tab によって %XML.SAX.ParserOpens in a new tab の既定のポート値が明示的に設定されます。以前のリリースでは、既定で、その %Net.HttpRequestOpens in a new tab オブジェクトを使用した最後の要求のポートが使用されました。
XML の変更
文字ストリーム入力 LineTerminator Implicitly の $CHAR(10) への暗黙的設定
今回のリリースでは、XMLSTREAMMODE="block" (既定値) である場合、XML ドキュメントからインポートされる文字ストリームの LineTerminator が暗黙的に $CHAR(10) に設定されます。 これにより、インポートが、従来の改行シーケンス ($CHAR(10)、$CHAR(13)、$CHAR(13,10)) と互換性を持つようになります。
MultiValue の変更
ULTIMATE エミュレーションでの STR.ONEISONE の既定の設定の変更
MultiValue BASIC プログラムをコンパイルする場合、従来の IN2 または ULTIMATE システムのエミュレーションを除いて $OPTIONS STR.ONEISONE フラグは既定で OFF になります。 以前は、STR.ONEISONE は、従来の IN2 システムの場合にのみ既定で ON になりました。 コンパイル時のエミュレーション設定のみがこの既定値に影響を与え、実行時の CEMU 設定の変更によって、コンパイル時のエミュレーション設定がオーバーライドされることはありません。
STR.ONEISONE フラグは、$OPTIONS フラグである IN2.SUBSTR および T のエイリアスです。これらの 3 つの $OPTIONS フラグによって、フォーム StringVar[N] の部分文字列参照の動作が変更されます。 これらのフラグのいずれか 1 つを使用する場合、StringVar[N] への参照は、変数 StringVar に含まれている文字列内の位置 N にある 1 つの文字への参照です。 これらのフラグのいずれも使用しない場合、StringVar[N] への参照は、位置 N から始まり、文字列変数 StringVar のコンテンツの終わりまでの文字列文字すべてへの参照です。
CEMU ULTIMATE コンパイル時設定 (または MV BASIC ソース・ルーチンの $OPTIONS ULTIMATE) を使用し、STR.ONEISONE フラグがオフになっていることに依存する場合、明示的に以下の文を含めることが必要になりました。
$OPTIONS -STR.ONEISONE
上記の文を、この変更によって影響を受ける MV BASIC ソース・プログラムに含めます。
Base64 エンコード XML からの既定としての改行の削除
このリリースから、既定では、タイプ %BinaryOpens in a new tab または %xsd.base64BinaryOpens in a new tab のすべてのプロパティの base64 エンコード XML 出力から改行が削除されるようになりました。改行を行うことを既定とするには、以下の手順を実行します。
-
XMLExport で、“base64linebreaks” を形式引数に追加します。
-
%XML.WriterOpens in a new tab で、BaseLineBreaks プロパティを 1 に設定します (既定値は 0 です)。
-
SOAP Web サービスまたは Web クライアント・バイナリ出力について、Base64LineBreaks プロパティを 1 に設定するか、BASE64LINEBREAKS パラメータを 1 に設定します。 両方のパラメータを設定すると、プロパティによってパラメータがオーバーライドされます。
BASIC と MVBASIC の変更
MultiValue プロセス・ロックの即座の解除
MultiValue プロセス・ロック (MVBASIC LOCK および UNLOCK コマンドで作成および解除される) は、トランザクションから独立していると想定されています。 ただし、以前のリリースでは、トランザクション中の UNLOCK コマンドでは、最も外側のトランザクションが終了するまでプロセス・ロックは解除されませんでした。 現在は、MV BASIC UNLOCK コマンドによって、アクティブなトランザクションがあるかどうかに関係なく、それに対応するプロセス・ロックが即座に解除されます。
UNLOCK コマンドでは最も外側のトランザクションが終了するまでプロセス・ロックは解除されないことに依存しているアプリケーションは、この動作の変更による影響を受けます。 以前に類似した動作を復元するための対応策は、プロセス・ロックの名前に関連するファイル名のダミー・ファイル上で取得されたファイル・ロックにプロセス・ロックを置き換えることです。 プロセス・ロックは、トランザクション内でも即座に解除されるようになりましたが、トランザクション内の FILEUNLOCK コマンドでは最も外側のトランザクションが終了するまでファイル・ロックの解除が遅延されます。
フィールド番号 0 を指定した WRITEV によるレコードの先頭への追加
以前のリリースでは、レコードの属性番号 0 に対する更新を指定する WRITEV 文の動作は未定義でした。今回のリリースから、MVBasic ランタイムが変更され、動的配列レコードの属性番号 0 に対する WRITEV によって、新しいデータがレコードの先頭に新しい属性として追加されます。 この新しいデータは、動的配列の先頭属性になり、前の属性はすべて位置が 1 つ上に移動します。 これは、動的配列変数の属性 0 に文字列値を割り当てることと類似しています。
xDBC の変更
ODBC 2.5 API の削除
以下の API は、Microsoft ドライバ・マネージャがバージョン 2.5 とバージョン 3.5 の両方を呼び出し中である場合のエラーに対処するために InterSystems ODBC 3.5 ドライバによってエクスポートされることはなくなりました。
-
SQLAllocConnect
-
SQLAllocEnv
-
SQLAllocStmt
-
SQLErrorW
-
SQLFreeConnect
-
SQLFreeEnv
-
SQLSetParam
-
SQLTransact
-
SQLGetConnectOptionW
-
SQLGetStmtOption
-
SQLSetStmtOption
日付と時刻およびタイムスタンプのバージョン 3.5 ドライバでの既定の C タイプの変更
ODBC C タイプ SQL_C_DEFAULT (99) は SQLBindColumn の呼び出しで使用でき、ODBC ドライバによって、指定された SQL_TYPE に基づいて適切な C タイプが決定されます。 ODBC 3.5 標準では、日付、時刻、タイムスタンプの SQL_TYPES が、9、10、および 11 から 91、92、および 93 にそれぞれ変更されました。SQL_C_DEFAULT(99) が C タイプとして指定されている場合、Caché では内部で適切な C タイプを返す SetDefaultType(sql_type) が呼び出されます。
以前は、ODBC 3.5 バージョンの Intersystems ドライバの場合、Caché は値が 91、92、および 93 の日付、時刻、およびタイムスタンプについて SQL Types を検出せず、SQL_C_CHAR として C タイプを返しました。これにより、実行時にエラーが発生しました。 現在は、SetDefaultType(sql_type) は、それぞれ 91、92、および 93 の日付、時刻、およびタイムスタンプについて SQL_TYPES を検出し、対応する C タイプである SQL_C_TYPE_TIME、SQL_C_TYPE_DATE、SQL_C_TYPE_TIMESTAMP (91、92、93) を返すようになりました。
DeepSee の変更
タイム・オフセットを基準にする NOW の再定義
DeepSee の時間レベルは、"timeOffset" 属性を使用した日付オフセットで構成できます。この機能については、ドキュメントで説明しています。この修正以前は、NOW という特殊なメンバの動作には不具合がありました。
年が “-6m” のオフセットで定義されているケースについて考えてみましょう。これは以下を意味します。
-
2014 = July 2013 to June 2014
-
2015 = July 2014 to June 2015
今回の明確化以前は、"NOW" の意味はオフセットに基づいて変化していました。したがって、同じ例について、DeepSee は NOW が 2014 年 7 月であると判断して、-6m オフセットを適用して 2014 年 1 月を取得し、-6m オフセットした年である 2014 年 1 月がどの年に属するのかについては、2014 年であると判断します。 要約すると、NOW を選択すると、現在の日付が属している期間が返されるようになりました。
この修正により、現在の日付が 2014 年 7 月である場合、年レベルは 2015 年が返されます。それは、2015 年の初めにマイナス 6 か月のオフセットを適用すると “NOW” は 2015 年の範囲内にあるためです。
計算メンバと計算メジャーとの区別の適用
MDX では、計算メジャーと、メジャーではない計算メンバとは区別されません。ただし、この区別を行うほうが実用的です。今回のリリースでは、DeepSee では、これらのアイテムはクロス結合に含まれている場合に区別されます。現在は、クロス結合で使用される 2 つのセットのうち、1 つのみにメジャー (またはメジャーのように動作するアイテム) を含めることができます。1 つのセット (または両方のセット) に、メンバ (またはメンバのように動作するアイテム) を含めることができます。このコンテキストでは、以下のようになります。
以前のリリースでは、以下のクエリが有効でした。
WITH MEMBER [ColorD].[DEMO] AS
'AGGREGATE({[COLORD].[H1].[FAVORITE COLOR].&[Blue],
[COLORD].[H1].[FAVORITE COLOR].&[Red],
[COLORD].[H1].[FAVORITE COLOR].&[Yellow]})'
SELECT NONEMPTYCROSSJOIN([COLORD].[DEMO],[Measures].[Test Score]) ON 1 FROM [Patients]
今回のリリースでは、この同じクエリでエラーが発生します。
ERROR #5001: Two measures cannot be crossjoined
この変更の結果、すべての計算メンバを確認し、それらがどのように使用することを意図されているかを考慮する必要があります。計算メンバがメンバとして使用されることを意図されている場合、%OR を使用します。メジャーとして使用されることを意図されている場合、AGGREGATE または別の数値関数を使用します。また、NONEMPTYCROSSJOIN または CROSSJOIN を使用するクエリを確認し、2 つのメジャーを意図せずクロス結合していないことを確認します。
リスト・レベルの複数メンバを除外する場合のクエリの変更
今回のリリースでは、ユーザがリスト・レベルの複数のメンバを除外する場合、DeepSee によって以前とは異なるクエリが生成されます。この新しい形式のクエリは、ユーザがリスト・レベルの単一メンバを除外する場合に DeepSee によって生成されるクエリと一致しています。この変更は、DeepSee エンジンに対する変更ではなく、単にユーザが (アナライザまたはダッシュボードで) フィルタ・ドロップダウンと対話するときの DeepSee でのクエリの生成方法に対する変更です。
例えば、リスト・レベルである、SAMPLES 内の Diagnosis レベルについて考えてみましょう。以前のリリースでは、ユーザがこのレベルの asthma および CHD メンバを選択し、[除外] オプションをクリックした場合、DeepSee によってクエリに以下のフィルタが追加されました。
%FILTER EXCEPT([DIAGD].[H1].[DIAGNOSES].Members,{[DIAGD].[H1].[DIAGNOSES].&[asthma],[DIAGD].[H1].[DIAGNOSES].&[CHD]})
このフィルタによって、asthma の診断 "のみ" を持つ患者と、CHD の診断 "のみ" を持つ患者のレコードが削除されます。ピボット・テーブルで Diagnosis レベルを行として表示すると、結果は以下のようになります。
Diagnosis | Patient Count |
---|---|
なし | 831 |
asthma | 7 |
CHD | 4 |
diabetes | 48 |
osteoporosis | 24 |
asthma のみを持つ患者は、このピボット・テーブルではどこにも含まれておらず、CHD のみの患者も同様です。このピボット・テーブルでは、asthma 行は、他の診断に "加えて" asthma の診断がある患者を表しています。同様に、CHD 行は、他の診断に "加えて" CHD の診断がある患者を表しています。これは有効な MDX クエリですが、ユーザが生成しようとしているクエリではありません。
今回のリリースでは、ユーザがこのレベルの asthma および CHD メンバを選択し、[除外] オプションをクリックした場合、DeepSee によってクエリに以下のフィルタが追加されるようになりました。
%FILTER ([DIAGD].[H1].[DIAGNOSES].&[asthma].%NOT,[DIAGD].[H1].[DIAGNOSES].&[CHD].%NOT)
このフィルタでは、asthma 診断を持つ患者と CHD 診断を持つ患者のレコードが削除されます。ピボット・テーブルで Diagnosis レベルを行として表示すると、今回は結果が以下のようになります。
Diagnosis | Patient Count |
---|---|
なし | 831 |
diabetes | 37 |
osteoporosis | 18 |
以前のリリースでは、DeepSee は、ユーザがリスト・レベルの "1 つの" メンバを除外する場合に %NOT 関数を使用していました。そして現在もこれを使用しています。例えば、ユーザが asthma を選択し、[除外] オプションをクリックすると、DeepSee によって以下のフィルタがクエリに追加されます。
%FILTER [DIAGD].[H1].[DIAGNOSES].&[asthma].%NOT
このフィルタによって、asthma の診断を持つ患者のレコードが削除されます。
ゼロ・パディング数値のエクスポートの文字列への変更
今回のリリースから、DeepSee では、KPI のプロパティの format 属性を “%string%” として定義できるようになり、そのようなプロパティの Excel エクスポートはその形式に従ったものになりました。つまり、以下のようなプロパティ定義があるとすると、
<property name="EnfUnit" displayName="EnfUnit" columnNo="3" format="%string%"/>
現在は、形式 0008 の数値が、数値としてではなく文字列として Excel にエクスポートされるようになりました。
キューブ・レジストリでの名前の必要性
今回のバージョンから、キューブ・レジストリを初めてロードしたときにダイアログが開くようになりました。これにより、ユーザは、トップレベルのレジストリ全体の設定のオプションと共にレジストリ・ストレージに使用されるクラス名の入力を要求されます。以前のリリースでレジストリが作成されている場合、以下のように実行できます。
-
新しいアクティブ・レジストリ・クラスとして既定のクラス名 DeepSee.CubeManager.CubeRegistryDefinition を入力することで、既存のものを再度開く。または
-
任意の名前で新しいレジストリを定義し、以前の DeepSee.CubeManager.CubeRegistryDefinition の Registry XData ブロックのコンテンツをコピーする。
保存とタスク・スケジュールの関数の分離
この変更により、スケジュール・コードが %DeepSee.CubeManager.Utils:WriteToRegistry() の呼び出しから削除され、それが %DeepSee.CubeManager.Utils:ScheduleUpdaterTasks() に配置されます。 現在は、後者の戻り値によってタスク・スケジュールの成功のステータスを確認することが可能になりました。 この変更により、WriteToRegistry() はキューブ・レジストリの検証および保存のみを実行し、ScheduleUpdaterTasks() がスケジュール要件の計算と関連タスクへの結果のパラメータの通信を行います。
CSP の変更
マルチパート要求ペイロードの個々のコンポーネント・ヘッダの解析の向上
以前のバージョンでは、個々のコンポーネントを保持している Caché ストリームに、ホストの形式で割り当てられた名前ではなく汎用 CSP ゲートウェイによって割り当てられた名前である “CONTENT” を使用して名前が付けられていました。
今回のリリースでは、マルチパート要求ペイロードの個々のコンポーネント・ヘッダの解析が向上しています。 ヘッダ行により多くのデータを含めることができ、個別のヘッダ行でさらなる処理が実行され、ペイロード (および関連する型情報) が正確に Caché に送信されるようになりました。
Zen レポートの変更
既定のテーブル幅の変更
今回のリリース以前は、テーブルの幅が指定されていない場合、Zen レポートによって “auto” の既定値が指定されました。現在は、新しい既定値である “100%” が指定されるようになりました。以前の既定値に依存しているレポートは、現在はそれを明示的に設定する必要があります。
コンポジット・アイテム内のテンプレートの処理
今回のリリースより前は、テンプレートがコンポジットに含まれている場合、それらは無視されました。 現在は、それらは定義されるようになりました。 これにより、レポート内に定義されているテンプレートとの競合が発生する可能性があります。
競合が発生した場合の対応策は、コンポジットまたはレポートのいずれかからテンプレートを削除し、1 つの場所でのみ定義されているようにすることです。 前はコンポジットではテンプレートがサポートされていなかったため、以前のレポートとコンポジットの組み合わせでそのような競合が発生した場合の最も簡単な修正方法は、それらをコンポジットから削除することです。
この発想は、現在はカスタム・クラスまたはコンポジットの XData に XSLT テンプレートまたは変数定義を含めることができ、それらはレポートで参照できるということです。 XData の生成ポイントは、クラスまたはコンポジットが含まれている場所ではないことに注意してください。 これは、テンプレートが XSLT ソースの最上位レベルで定義される必要があるためです。
Y 値が存在しない場合に xyChart でデータセットにポイントが含まれない
以前のリリースでは、y 値が欠落している場合、Caché によって y に 0 の値が割り当てられ、マーカ・ポイントが描画され、xyChart で接続線が定義されている場合は、そのマーカ・ポイントを通過する線が描画されます。 現在は、y 値が “” であるか、定義されていない場合、xyChart の (x,y) ペアはスキップされ、マーキング・ポイントは描画されません。
すべてのバッチ/コマンド・ファイルおよび Java コマンドの構成可能メモリのサポート
今回のリリースから、レポートを作成するための新しいバッチ・ファイルの要件が導入され、既定の最大メモリ・サイズ (-Xmx 512m) を受け入れるか、環境変数を指定することが必要になりました。 これより前は、サーバ・スクリプトにそのような引数が含まれていました。それは、メモリがマシン上の物理メモリの量に応じて割り当てられることを意味しています。 適切な方法は、メモリ・サイズの指定を適用することです。
さらに、以下の環境変数が定義されています。
-
EXCELMEMSIZE、EXCELSERVERMEMSIZE
-
FOPMEMSIZE、RENDERSERVERMEMSIZE
-
PRINTSERVERMEMSIZE
-
SAXMEMSIZE
-
PDFMERGEMEMSIZE
これらは既定で 512m になります。 サーバの場合、既定値はマシン上の物理メモリの量によって決定されていましたが、これは適切でない方法であり、現在はサーバの既定値は 512m になりました。 このメモリ・サイズを大きくするには、環境変数を使用します。
この変更は、OpenVMS では実装されていません。