You'll probably want to call Solr commit, however you'll want to
call IW.flush underneath (via a new Solr commit flag?).
Yes, the Solr caches would be somewhat useless if you're calling
Solr commit/flush rapidly. See SOLR-1308 on improving caches for
NRT.
On Tue, Aug 25, 2009 at 7:22 PM, KaktuCha
So basically the idea is to replace the underlying IndexReader currently
associated with a searcher/solrCore following an update without calling
commit explicitly? This will also have the effect of bringing in inserts
btw? or is it just usable for deletes?
In terms of cache invalidation etc there
I can give an overview, IW.getReader replaces IR.reopen. So
you'd replace in SolrCore.getSearcher. However as per another
discussion IW isn't public yet, so all you'd need to do is
expose it from UpdateHandler. Then it should work as you want,
though there would need to be a new method to create a
Jason,
sounds like a very promising change to me - so much that I would gladly work
toward creating a patch myself.
Are there any specific points in the code u could point me to if I wanna
look at how to start off implementing it?
Lucene/Solr Classes involved etc? i'll start looking myself anyhow
This will be implemented as you're stating when
IndexWriter.getReader is incorporated. This will carry over
deletes in RAM until IW.commit is called (i.e. Solr commit).
It's a fairly simple change though perhaps too late for 1.4
release?
On Tue, Aug 25, 2009 at 3:10 PM, KaktuChakarabati wrote:
>
>
