こんにちは、Dima。

スキーマがアトミックアップデート用に正しく構成されていれば、子ドキュメントもアトミックに追加できます。個別の子ドキュメントを追加、置換、削除したい場合は、JSONリクエスト形式を使用する必要があります。これらのアップデートはXMLを通じてサポートされていません（SOLR-12677）。

Thomas

私の理解では、アトミックアップデートにはすべてのフィールドが格納されるか、または docValues = true である必要があり、それは _root_ および _nest_path_ のデフォルト定義ではそうなっていません。

さらに、デフォルトのスキーマでは _text_ フィールドは格納されることも docValues = true でもなく、copyField の指示が「すべてを二重にインデックス化するのは非常に高価だから」という理由でコメントアウトされています。（これはおそらくバグです：フィールド定義もコメントアウトされた部分内にあるべきです。）

つまり、デフォルトで作成されるスキーマはアトミックアップデートには適していないということですか？（それでも「フラット」なドキュメントでのアップデートコマンドは問題なく動作しているようです。）

ありがとう、
Dima

追伸：考え直してみると、docValues = true は _nest_path_ のデフォルト設定のようなので、アトミックアップデートの要件に適合していないのは _root_（および text ですが、これはおそらくデフォルトスキーマの記述ミスです）だけです。

Dima

こんにちは、
この核心問題についてはよく理解できませんが、SQLクエリに関する最後の文について詳しく説明したいと思います。以前、構造化モデルのETL作業に取り組んだ経験があります。SQL用語でいうところの「外部マージ結合」が、このようなインデクサーに対して非常に効果的であることがわかりました。我々はこれをDIHで「ジッパー結合」として実装しました。
以下のリンクを参照してください：

• Data Import Handler
• SOLR-4799
  DIHへの移行を推奨するわけではありませんが、N+1問題を避けるために外部SQL結合を検討することを提案します。

成功をお祈りします。

これは話題が逸れてしまいますが、ポイントはDIHからの移行です。過去数週間、db-data-config.xmlを（Pythonの）スクリプトに書き換える作業を行っており、いくつかの点で問題が発生しました。以下はその例です：

• cacheKey/cacheLookupが使用できない。
• child=trueがうまく機能せず、現在その解決に取り組んでいる。
• onError=continue：スクリプトではパフォーマンスのためにドキュメントのバッチをPOSTしますが、404エラーが発生するとバッチ全体が失敗します。実際のエラーを修正したい場合が多いので、これは「バグではなく機能」と考えるべきかもしれません。

DIHを廃止した理由は理解できますが、その代替機能はまだ完全ではないように思います。開発者は再考すべきかもしれません。

Dima