Hi Antony, Why not use CachingWrapperFilter together with a TermsFilter or QueryWrapperFilter(TermQuery)? This Filter keeps track of all used segment readers. So you build an instance: Filter f = new CachingWrapperFilter(new QueryWrapperFilter(new TermQuery(new Term(...))));
And reuse that filter instance with all queries, the user starts. No need to hack the cache yourself. The above variant is much more effective as it works better with reopen()'ed index readers (after index changed), because it reuses the unchanged segment readers. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Antony Bowesman [mailto:[email protected]] > Sent: Tuesday, April 19, 2011 7:30 AM > To: Lucene Dev > Subject: Filters with 2.9.4 > > Hi, > > Another migrate to 2.9.4 issue for me... > > When a search is done by a user, I collect a 'DocSet' of Documents for that > 'owner' (Term("id", "XX)). This is a single set for all Documents in the index > and NOT per reader. > > Then when searches are made I use caching Filters, but I use my master > DocSet as a Filter for those chained Filters. However, with 2.9, Filters are > now called per segment reader and there's a DocIdSet for each Reader. > There is no way for the filter implementation to know the docBase for the > passed reader, like the collector does. > > As the Javadocs for Filter.getDocIdSet imply, a Filter must only return doc ids > for the given reader. > > I am now stuck with a filter implementation that can no longer interset the > master bitset for my 'owners'. > > Was this envisaged during the changes and is there a way I can get hold of > the docBase for an IndexReader. > > Thanks > Antony > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
