ORDAで作成したエンティティセレクションには固有のORDAコンテキストが関連づけられます。ORDAのコンテキストを作成するコマンドは,下記のとおりです。
dataClass.query()
entitySelection.query()
dataClass.fromCollection()
dataClass.all()
Create entity selection
Use ORDA to boost performance in Client/Server mode
ORDAのコンテキストは,クライアント/サーバーのパフォーマンスを最適化するために使用されます。具体的には,REST APIでサーバーから転送されるデータクラス属性のリストを内部的に管理し,リクエストされた属性だけを追加してゆくことにより,クエリの特性を自動的に「学習」するために使用されます。通常,コンテキストを意識してコーディングする必要はありませんが,条件分岐を含むエンティティセレクションの一括処理などでアクセスする可能性のあるすべての属性が事前にわかっているのであれば,最初に必要な属性名すべてにアクセスしてコンテキストを最適化することにより,一括処理の途中で不足した属性を補うためのネットワークリクエストが発生することを防ぐこともできます。コンテキストはフォームの描画にも使用されており,リストボックスのカラム内で使用されている属性(非表示カラムを含む)が初期コンテキストとなります。
ORDAコンテキストは,クエリの用途に対して特化されたものであるべきです。コンテキストから属性を除外することはできないので,コンテキストを汎用的に使用した場合,属性のリストが肥大化してパフォーマンスが低下する恐れがあります。リレーション属性にアクセスする場合は特にそうです。たとえば,下記のコードはマルチレベルのリレーション属性にアクセスしているため,指数的にコンテキストが肥大化し,一括処理の後は非常に処理が重くなります。ORDAリクエストログをみれば,一括処理の後,レベルのリレーション属性がそれぞれ最大80
件ずつ返されていることがわかります。
$logFile:=Folder(fk logs folder).file("ORDARequests.txt")
ds.startRequestLog($logFile)
$entitySelection:=$anEntity.relatedEntities
For each ($entity; $entitySelection)
$relatedData:=$entity.link.link.link.link.toCollection()
End for each
$result:=$entitySelection.orderBy() //重い処理
コンテキストが肥大化してしまった場合,dataClass.get()
で新しいコンテキストを作成することができます。
$logFile:=Folder(fk logs folder).file("ORDARequests.txt")
ds.startRequestLog($logFile)
$entitySelection:=$anEntity.relatedEntities
For each ($entity; $entitySelection)
$relatedData:=$entity.link.link.link.link.toCollection()
End for each
$key:=$anEntity.getKey() //プライマリーキー
$entitySelection:=ds[$anEntity.getDataClass().getInfo().name].get($key) //新しいコンテキスト
$result:=$entitySelection.orderBy() //軽い処理
v14でACI0084254が修正されたことにより,環境設定の「アプリケーションモードに移動する時にデザインモードを終了する」が有効にされていない場合,カスタムモードでは常にスプラッシュスクリーンが表示されるようになりました。その場合,データベース設定の「インターフェース」ページで「スプラッシュスクリーン」をオフにしても,スプラッシュスクリーンが強制的に表示されます。これは仕様です。
カスタムモードでメニューバーを表示するためには,メインプロセスが最前面でなければならず,プロセスが最前面であるためには,ウィンドウを表示していなければなりません。ACI0084254の修正前,環境設定の「アプリケーションモードに移動する時にデザインモードを終了する」が有効にされておらず,データベース設定の「スプラッシュスクリーン」もオフに設定されている場合,カスタムモードからデザインモードに切り替えた後,カスタムモードに復帰することができませんでした。修正により,環境設定の「アプリケーションモードに移動する時にデザインモードを終了する」が有効にされていない場合,強制的にスプラッシュスクリーンが表示されるようになりました。
Apple Silicon版の:macOS Big SurでGet application info
を実行した場合,cpuUsage
プロパティに-1
が返されます。これは仕様です。コマンドは内部的にthread_infoを使用していますが,Rosettaで動作しているIntelアプリケーションには,CPUの情報が返されないようです。
HTTP SET OPTION
で設定できるHTTP timeout
は,接続タイムアウトではありません。v18/19の初期リリースは,実装が間違っており,サーバー接続タイムアウト(サーバーがダウンしている場合,いつまでもレスポンスを待ち続けるようなことを避けるためのタイムアウト)にこのオプションが適用されていました。正しい動作は,HTTPレスポンスのタイムアウト(サーバーとの接続が確立された後,HTTPレスポンスが返されるまで待機する時間の上限)です。
更新:
下記の不具合修正も参照
HTTP SET OPTION
のHTTP timeout
オプションがHTTP Get
の動作に反映されませんでした。つまり,サーバー接続に成功し,なかなか応答が返されず,切断もされない場合,いつまでもレスポンスを待ちました。HTTP Request
を続けて何度も実行した場合,#17
(未実装の制御命令)エラーが返されることがありました。実際にはタイムアウトエラーが発生しています。HTTP SET OPTION
で設定した秒数以内にレスポンスを読むことができなかった場合にエラーが返されます。DIALOG
コマンドで表示したダイアログは,確定またはキャンセル後にウィンドウが自動的に閉じられますが,明示的にCLOSE WINDOW
で閉じることが推奨されています。たとえば,Movable form dialog box
でダイアログ表示した直後,CLOSE WINDOW
を呼び出さずにCreate document
などのファイルシステムコマンドを実行した場合,モーダルウィンドウ閉じられる前にウィンドウが表示されてしまい,背後のウィンドウが操作できなくなるかもしれません。