Yeah, it seems like newsearcher ought to apply to both cases and first searcher should only need to exist if something must be done only at boot/creation, duplication should not be necessary. (in an ideal world)
On Wed, Sep 9, 2026 at 3:22 PM David Smiley <[email protected]> wrote: > I believe it's common to configure firstSearcher & newSearcher similarly. > The duplication in configuration (e.g. of warming queries) is annoying. > Wouldn't it make sense for a "first searcher" event to be considered *not > only* the "first" searcher but also inherently a "new" searcher as well? > Thus to simply configure a set of queries to run for *all* searchers, one > would only configure newSearcher, knowing it applies to both replacement > searchers (for after a commit, bascially) as well as first/oriignal > searchers. Note that a core reload is also a firstSearcher scenario. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
