Solr8.11のドキュメント「JSON更新コマンドの送信（Sending JSON Update Commands）」にバグ？
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/gr9yy7gh14rzbdcny77995sdyrjr8t64 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
TFMの例では、2つの「add」キーと2つの「delete」キーを含むJSON配列が示されており、これは合理的なプログラミング言語で生成することはできません：
url -X POST -H 'Content-Type: application/json' 'http://localhost:8983/solr/my_collection/update' --data-binary '
{
"add": {
"doc": {
"id": "DOC1",
"my_field": 2.3,
"my_multivalued_field": ["aaa", "bbb"]
}
},
"add": {
"commitWithin": 5000,
"overwrite": false,
"doc": {
"f1": "v1",
"f1": "v2"
}
},
"commit": {},
"optimize": {"waitSearcher": false},
"delete": {"id": "ID"},
"delete": {"query": "QUERY"}
}'
これはドキュメントのバグで、外側のレベルは実際にはリスト（何のリスト？）であることを意味しているのか、それとも本当に上記の文字列を期待しているのでしょうか？
誰か教えてくれませんか？
Dima
まあ、Dmitry, JSONのキーは一意であるべきですが、必ずしもそうであるとは限りません。任意の合理的なプログラミング言語でストリーミングライターやリーダーについて考えることができます。
DOMスタイルのパースについて言えば、マップに制限されることはなく、バッグや素晴らしいSolrのNamedListを使用することもできます。
見た目はそうかもしれませんが、検索でボディペイロードを持つHTTP GETほど衝撃的ではありません。
--
心からの敬意を込めて
Mikhail Khludnev
そうですね、ちょうどパラシュートが降下中に開くべきだが、必ずしもそうではないのと同じです。
もちろん、私は好きなように文字列を手書きで作成し、それを読むためのパーサーも手書きで作成できます。しかし、JSONはJavaScript Object Notationを意味します。もし文字列が有効なJavaScriptオブジェクトにデマシャリングできなければ、それは地面に落ちて粉々になります。
Dima
重複するキーは多少驚きですが、絶対に許容されており、これまでもそうでした。
ECMAのJSON仕様から引用します：
「JSONの構文は名前として使用される文字列に制限を課さず、名前文字列が一意であることを要求せず、名前と値のペアの順序に意味を持たせません。」
https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
しかし、Solrはその仕様の「名前と値のペアの順序に意味を持たせません」という部分から逸脱しています。更新リクエスト内の "add" と "delete" の順序は重要です。
Thomas
そうですね、一連の コマンドを送信するために辞書（Pythonの言葉で）を使用する際のもう一つの問題は、辞書のキーが本質的に順序付けられていないため、実装が自由に順序を変えて、例えば最初にコミットを実行し、その後すべての追加を行い、その後削除を行うことができることです。
しかし、その文字列が辞書にデマシャル（デシリアライズ）できないのであれば、それで大丈夫だと思います。
Dima
トピックへ返信するには、ログインが必要です。