一部の属性を更新する遅延ジョブをデプロイするモデルがあります。モデルは「検索可能」と宣言されています...
searchable do
text :content, :stored => true
end
...保存後に再インデックスすると思っていました。テストでは、これは当てはまらないようです。実行すると: rake sunspot:reindex
、すべてが期待どおりに機能します。この問題の原因は何ですか?
一部の属性を更新する遅延ジョブをデプロイするモデルがあります。モデルは「検索可能」と宣言されています...
searchable do
text :content, :stored => true
end
...保存後に再インデックスすると思っていました。テストでは、これは当てはまらないようです。実行すると: rake sunspot:reindex
、すべてが期待どおりに機能します。この問題の原因は何ですか?
Jason が述べたようにSunspot.commit_if_dirty
、クライアントからコミットを発行するために呼び出すことができます。
サーバー構成側からは、インデックスに変更が加えられたときにコミットを自動的に発行するようにautoCommit
プロパティを設定する別の方法があります。solrconfig.xml
ほとんどのmaxTime
サイトでは、60000 ミリ秒 (1 分) で十分です。
autoCommit
大量のコミットが Solr サーバーのパフォーマンスに影響を与えやすい本番アプリケーションでは、使用する方がおそらく賢明な選択です。実際、サイトがかなりの量の更新を取得し始めたら、Sunspot を無効にすることをお勧めします。auto_commit_after_request option
最後に、autoCommit
設定して忘れることができるという利点があります。
Websolrでは、デフォルトで、クライアントが発行したコミットを無視してautoCommit
.
Sunspot.commit
インデックスは、が呼び出された後の変更のみを反映します。これは、 を実行すると自動的に行われますrake sunspot:reindex
。
Sunspot の Rails プラグインには、すべてのリクエストの後auto_commit_after_request
に呼び出される構成オプションもありますSunspot.commit_if_dirty
が、これはバックグラウンド プロセスによってトリガーされません。
あなたの最善の策はSunspot.commit_if_dirty
、遅れた仕事の最後のこととして後に電話することです.
私はあなたとまったく同じ問題を抱えていました.検索機能をテストしていたとき、sunspotはsolrにコミットを発行しませんでした. Sunspot.commit を手動で呼び出すと、すべてが機能します。auto_commit_after_request をいじりましたが、これはデフォルトで true であるため、違いはありません。
そのため、さらに調査した結果、Web リクエストのコンテキストで変更が行われない限り、Sunspot は自動的にコミットを発行しないことがわかりました。テストまたはバックグラウンド ジョブから変更を行う場合は、Sunspot.commit を手動で呼び出す必要があります。