Solr has the notion of "soft commit" and "hard commit". A soft commit
means Solr will reopen a new searcher. A hard commit means a flush to disk.
All the update/delete logics are in Lucene, Solr doesn't maintain deleted
doc IDs. It does maintain its own caches though.
On Jul 14, 2014, at 03:09 AM
How Solr handles this scenario... Is it reopening reader after every
delete OR it maintains the list of delete documents in cache?
Regards
Ganesh
On 7/11/2014 4:00 AM, Tri Cao wrote:
You need to reopen your searcher after deleting. From Java doc for
SearcherManager:
In addition you should
Are you sure the deletes are "working"? Ie, the terms you are
deleting by in fact match the documents you are trying to delete?
(Try instead searching on those terms, to make sure they really do
match the docs...).
Can you boil this down to a small test case?
Mike McCandless
http://blog.mikemcc
Thanks for the advice. I forgot to mention, I am already calling
searcher.maybeRefresh() immediately after deleting the documents.
Furthermore, searcherManager is being instantiated with applyAllDeletes
set to true. We are using the searchAfter function. Under these
circumstances, the deleted i
You need to reopen your searcher after deleting. From Java doc for
SearcherManager:
In addition you should periodically call maybeRefresh. While it's possible to
call this just before running each query, this is discouraged since it
penalizes the unlucky queries that do the reopen. It's better
Hi
I am using NRT search with the SearcherManager class. When the user
elects to delete some documents, writer.deleteDocuments(terms) is called.
The problem is that deletes are not immediately visible. What does it
take to make them so? Even after calling commit(), the deleted
documents are
