プロダクション solr インデックスのデータを制御する必要があり、新しい開発と互換性がある必要があります。理想的には、ローカル マシンでインデックスをモックし、solr でクエリを実行し、ユニット テストを記述してクエリを実行し、反復を高速化します。
RamDirectory は別の質問で同様のことを行うために使用されますが、質問は2年前のものです。この例は、まさにそれを行っているように見えます (RamDirectory の代わりに FSDirectory を使用)。これらは、この問題に対する正しいアプローチですか? これを行うためのより良い方法はありますか?
次のようなテストを書きたいと思います:
setup mock index;
query mock index;
assert(stuff that should be true);
teardown mock index;
編集:追加の詳細:
私たちの考えでは、インデックスを作成し、バージョン管理で保持できるローカル データベースを除いて、インデックス作成者やシステムの残りの部分を必要とせずにドキュメントを追加する簡単な方法を用意することでした。以前はインデックスを生成し、非互換性が発生したときにインデックスを再生成していました。
インデックスを再作成すると、多くのオーバーヘッドが追加されます。インデクサーには多くのデータ処理ロジックが含まれているため (データベースから検索可能なフィールドにデータを追加するなど)、インデクサーをモックすることは適切なオプションとは思えません。 . 私たちのインデクサーは外部データベースに接続するので、それもサポートする必要があります。上記のように、オーバーヘッドがほとんどないローカル テスト データベースを使用できます。
テスト データベースを作成したら、インデックスを作成する必要があります。その後、上記の 2 番目のリンクから進むことができます。問題は、たとえばサイズが 1000 のドキュメントについて、テスト用に非常に迅速にインデックスを構築するにはどうすればよいかということです。
これに関する問題は、ローカル データベース スキーマを本番スキーマと同期させておく必要があることです。本番スキーマは頻繁に変更されるため、これが問題になります。これを処理するのに十分な柔軟性を備えたテスト インフラストラクチャを用意したいと考えています。現在のアプローチでは、毎回データベースを再構築するだけですが、これは遅く、他の人を怒らせます。