Solr 9.7.0 が `fl` パラメータを使用した場合、フィールドの順序が異なる結果を返す
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/ogmz3ggfbs2y00dwmb0grjvxc5mr0o4t into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
Solr 9.6.1 までは、fl パラメータを使用すると、フィールドは保存されている順序で返されていたようです。しかし、Solr 9.7.0 では、フィールドが異なる順序で返されるようになっています。
以下はその例です：
Solr 9.6.1 の場合（fl パラメータを使用）
{
"responseHeader": {
"status": 0,
"QTime": 2,
"params": {
"q": "price:[70 TO 80]",
"fl": "id,price"
}
},
"response": {
"numFound": 1,
"start": 0,
"numFoundExact": true,
"docs": [{
"id": "VS1GB400C3",
"price": 74.99
}]
}
}
Solr 9.7.0 の場合（同じクエリとフィールドリスト）
{
"responseHeader": {
"status": 0,
"QTime": 44,
"params": {
"q": "price:[70 TO 80]",
"fl": "id,price"
}
},
"response": {
"numFound": 1,
"start": 0,
"numFoundExact": true,
"docs": [{
"price": 74.99,
"id": "VS1GB400C3"
}]
}
}
この変更によって、フィールドの順序が以前と異なり、統合テストが失敗しています。このフィールドの順序を以前と同じように保持する方法はあるのでしょうか？
期待結果を変更するのは困難です。なぜなら、これらのテストは複数の Solr バージョンで動作する必要があるからです。
Thomas
注意が向いていない間に何かが変更されていなければ、レスポンス内のフィールドの順序は保証されていません。Jiraをいくつか調べたところ、フィールドの順序に関する問題はバージョン1.3以来、「修正しない（WONTFIX）」とされています：
https://issues.apache.org/jira/browse/SOLR-1190
そもそも、通常、JSONにおけるキーの順序が保証されることは期待されません。JSONの仕様によれば、名前と値のペアは順序がないとされています：
https://www.json.org/json-en.html
→「オブジェクトは名前と値のペアの無順序セットである。」
私たちのコードの多くの場所では、フィールドを保持するために LinkedHashMap を使用しています。これにより、コードを読んでいると順序が保証されているように見えるかもしれませんが、これは順序のためではなく、イテレーションコストのメリット（エントリ数に対してスケールする、容量ではなく）を目的としていると考えています。（ただし、コードベース内にはいくつかの例外があります。この点については以下の愚痴で説明します）。
SolrのJSONの使用方法にはいくつか問題があり、「正しくないコンマ」を許容してエラーをスローしない場合があります（これは noggit の意図的な機能ですが、私は好きではありません）。さらに、知っている限りでは、キーの重複を許容しているケースもあります：
https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-with-update-handlers.html#sending-json-update-commands
これは技術的には合法なJSONですが、RFCでは明確に推奨されていません：
https://www.rfc-editor.org/rfc/rfc7159#section-4
その更新フォーマットでは、キーが実行する操作を示しているため、順序が暗黙的に重要です。しかし、これは仕様では保証されていません。この設計には常に苛立たされてきました。なぜなら、JSON仕様が完全に準拠するパーサーに求めていない動作に依存しており、またキーの重複に依存しているからです。このようなケースは非常に珍しく、多くの人が予期せず、ライブラリでも十分にサポートされていません。
さらに、JSON.orgのシンプルな仕様でさえ、オブジェクトが他の言語の「オブジェクト、レコード、構造体、辞書、ハッシュテーブル、キー付きリスト、または連想配列」を表すことを意図していると参照していますが、これらのほとんどは重複キーを許可していません。そのため、この動作を明確に排除しなかったとしても、ある程度の意図を推測できます。
このようなオブジェクトをJavaやJavascriptにマッピングして操作するには、シンプルなオブジェクトマッパーではなくカスタム処理やデータ構造が必要になります。例えば、次のように設計すべきでした：
[
{ "operation": "ADD", "parameters": {...} },
...
]
これなら順序が保証され、どこでも簡単に利用できるデフォルトのマッパー設定で処理できます。
Jiraリンクをありがとうございます。
別の例として、Lukeリクエストで show=doc を使用し、ドキュメントに multiValued フィールドが含まれている場合、重複キーを含むJSONが出力されることがあります。
そのような構造をサポートしない言語で解析するのはいつも楽しいですね。
トピックへ返信するには、ログインが必要です。