問題タブ [marklogic-dhf]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
marklogic-9 - MarkLogic : クエリ オプションと変換に関する設計上の質問
私たちのチームは一連のカスタム REST API (v1/resources/...) を作成し、それらをエンタープライズ サービスとして、MarkLogic について何も知る必要のない他の利害関係者に公開します。ただし、私たちのチームは、MarkLogic 内のサーバー側スクリプト (JavaScript を使用) の作成、拡張、および保守を担当しています。
カスタム REST API を作成する際、検索要件を満たすための現在の設計は、クエリ オプションから開始し、クエリ オプションにできるだけ多くの要件を組み込み、クエリ オプションで満たすことができなかった要件 (ドキュメント内の並べ替えなど) を処理することです。 、複雑な XPath、他のドキュメントとのマージなど)、Java Script 拡張プログラム内のコード (技術的には変換ではありませんが、概念的には変換に似ています)。
クエリ オプションの制限により、ほとんどのロジックが Javascript 拡張プログラムに組み込まれることが多くなり、クエリ オプションは単なるメンテナンス オーバーヘッドのように見えます。変換は非常に強力な機能を提供しますが、REST 拡張機能ごとにクエリ オプション ファイルを維持する必要があるのでしょうか。クエリ オプションを削除して、サーバー サイドの Java Script コードのみを使用することはできますか (概念的には変換に似ています)? 当初、クエリ オプションは構成ベースであるため、クエリ オプションの変更は正確にはコードの変更ではないと考えていましたが、経験に基づいて、クエリ オプションの変更にはデプロイ、回帰テスト、およびその他すべてのアクティビティも含まれることに気付きました。したがって、私たちの場合 (カスタム REST API の作成) では、クエリ オプションの特定の利点は見られません。
デザインの達人、提案してください！