Hi Peter, I think this is already taken care of by CachingWrapperFilter - because its caching is (like filtering) by IndexReader, and search by a multiSearcher eventually attempts to filter against each underlying reader, and those "sub-" filters are being cached.
So it seems to me that if you just create a cachingWrapperFilter around your (I assume) RangeFilter, the caching for the underlying searchers would happen "by itself" - as long as the searchers are reused. Did you actually try that and it didn't work? Regards, Doron "Peter Goldstein" <[EMAIL PROTECTED]> wrote on 24/04/2007 10:14:36: > All, > > > > I'm looking to solve the following problem and I could use some help. > My preferred approach appears to be blocked by Java permissioning, and > I'm not sure if that's by design or by accident. > > > > I have a set of search fixed indices that get built on a 5 hour cycle - > these indices are not updated during their lifetime, so the document ids > are never updated. I am adding "by date" filtering capability to the > document search. The most common form of this date filtering will be > either 'in the last week' or 'in the last month', both of which should > restrict to a constant set of documents over the lifetime of the > indices. Because of performance concerns I'd like to compute this > result once for each index and cache it, using a CachingWrapperFilter. > However it must be possible to run queries over multiple indices and > combine the results, for which we're currently using MultiSearcher. > > > > The MultiSearcher class doesn't have any kind of interface that allows > one to specify multiple filters, each assigned per-index. No other > obvious solution presented itself, so I figured I'd take the > MultiSearcher implementation and modify it to support this > functionality. However I soon discovered that it was accessing classes > and constructors (HitQueue, the TopDocs constructor) that have package > permissions. So I couldn't just cut and paste the code into a class in > another package. > > > > Was there any architectural reason that these classes and constructor > were assigned package permissions? If not, would it be possible for me > to get these changed to public in the next release? I'm happy to run a > modified Lucene package with updated permissions here for a short time, > but I'd like to make sure that it's a temporary situation. > > > > And on a more global note, does this approach sound reasonable? Is > there an easier way to accomplish what I'm trying to do? > > > > Any help would be appreciated. Thanks much. > > > > --Peter > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
