> If you add things that will appear in the javadoc then they need
> javadoc comments.
OK... thats not a problem.
> Also, I assume that the reason you make the reader field protected is
> because getReader() is not sufficient, i.e., you want to set the
> reader. This would stylistically be better done with a setReader()
> method, no? Do you only change it at construction, or at runtime? If
> you only change it at construction, then super(reader) in the
> constructor might suffice.
We change it at runtime. This is a ReloadableIndexSearcher that I
developed that can reload if an index has been optimized() or added to
by another external process. I just have my external process do the
merger and then call reload() on the main index. The cool thing about
this approach is that the entire webapp is operational while this
happens. While the swap is happening searches just backup for a second
and then complete. It also doesn't require 2x memory because I can
dispose of the current reader, block searches, then open the new reader.
I was going to contribute this patch but it requires the
edu.emory.mathcs.backport.java.util.concurrent package which is a
backport of the JDK 1.5 java.util.concurrent stuff.
> The reason I ask is that folks might cache things for a Searcher, and
> these might be invalidated if the reader changes, thus we shouldn't
> make it too easy to change the reader. Lucene's built-in caching is
> all keyed by the IndexReader, not the Searcher, so should not be
> broken by such an addition.
Why don't we do this. I don't think we should have a setReader then.
This way there's no strong contract that developers preserve things that
might break caching. I'd like to keep the protected change though.
This way it's a way of accepting that I'm taking my life in my own hands
and developers don't have to deal with anything more complex.
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.