ORDAクエリにおける属性パスのプレースホルダー

Deeplからの自動翻訳

4D v17 R5でORDAの機能が続々登場!以前のブログ記事で、値に名前を付けたプレースホルダーを使った汎用クエリの作成方法を紹介しました。今回は、属性パス(テーブルのフィールド名)にプレースホルダーを使用する方法に焦点を当てます。

HDI: ORDAクエリにおける属性パスのプレースホルダーの例

プレースホルダーには2種類あります。

インデックス付きプレースホルダー

属性パスにインデックス付きプレースホルダーを使う例を見てみよう。名前が “Bravo “で始まり、コメント欄に “New client “を持つクライアントを見つけたい。

C_OBJECT($clients)
$clients :=ds.Clients.query(":1 = 'Bravo@' and :2 = 'New client'"; "name"; "comment")

プレースホルダーは、クエリー文字列の :paramIndex(例: :1、:2、…、増分: 1) として挿入される。対応する値は、一連の値パラメータによって提供されます。

名前付きプレースホルダー

名前付きプレースホルダーも使用できます。名前つきプレースホルダーは、値に対する名前つきプレースホルダーと同じ概念を使用しています。パラメータは :paramName として挿入され、その値はクエリ文字列で提供されます。

C_OBJECT($clients;$settings)
$settings :=New object
$settings .attributes:=New object("pathOfName"; "name"; "pathOfComment"; "comment")
$clients :=ds.Clients.query(":pathOfName = 'Brabo@' and :pathOfComment = 'New client'";$settings
)

なぜプレースホルダーを使うのか?

では licencesInfoオブジェクト・フィールドを見てみましょう。これは、 licenceName:numberのスタイルでライセンス数を示しています。

{"licencesInfo":
{"4DDevPro":10,//This client has 10 4DDevPro licences
"4DServerV17_2":18,
"4DWebappserverV17_2":23}
}
.

4DDevPro」のライセンス数を調べるには、次のようなクエリーを記述します。

C_OBJECT($clients)
$clients :=ds.Clients.query("licencesInfo.4DDevPro >=0")

しかし、今度はこの licencesInfoオブジェクト・フィールドを見てください。属性パスにプレースホルダーを使用すると、プロパティ名がドット記法に準拠していないオブジェクトを照会する際に特に有効であることがおわかりいただけると思います

{"licencesInfo":
{"4D Dev.Pro":10,//This client has 10 4D Dev. Pro licences
"4D Server V17.2":18,
"4D Web app/server V17.2":23}
}
.

この場合、パラメータを文字列の集まりとして提供することで、クエリによって属性パスとして解釈されるため、問題が解決されます。

C_OBJECT($clients)
$clients :=ds.Clients.query(":1 >=0";New collection("licensesInfo"; "4D Dev. Pro")
)

プレースホルダーを使用するメリットはそれだけではありません。プレースホルダーを使うことで、悪意のあるコードの挿入を防ぐことができるため、セキュリティの面でも優れています。また、書式や文字の問題を気にする必要もありません。挙げればきりがありません。

上の例ではdataClassに対してクエリを発行していますが、ドキュメントを確認すると、コレクションに対しても適用可能であることがわかります。また、プレースホルダーを使用することがなぜ良いことなのかを示す例もたくさんあります。

Avatar
- プロダクトオーナー - Marie-Sophie Landrieu-Yvertは、2017年にプロダクトオーナーとして4Dプロダクトチームに参加しました。プロダクトオーナーとして、彼女はユーザーストーリー(ユーザーが期待する新機能とその使用法)を書き、それを具体的な機能仕様に変換する役割を担っています。また彼女の役割は、実装された機能が顧客のニーズを満たしているかどうかを確認することでもあります。彼女は1995年にESIGELEC Engineering Schoolを卒業し、IBMでエンジニアとしてのキャリアをスタートさせました。様々なプロジェクト(保守や新規のプロジェクト)に参加し、Cobolのデベロッパーとして働きました。その後、UMLデザイナーおよびJavaデベロッパーとして勤務。最近は、機能要件の分析・記述、ビジネスチームと開発チームの調整などを主に担当しています。