I would suggest *not* using caching inside of filters provided by lucene but rather provide a wrapper to do the caching. The reason is that some applications really don't want the libraries they use to be a source of concern for memory usage. i.e. if I search for a string using 10,000 different date filters (an extreme example, but possible) I want the ability to control how those bitsets are going to be > cached.
In the case of QueryFilter, simply construct a new one to avoid caching rather than reuse the same instance. So you have control there as well. The only thing that is cached is a BitSet, so it should be much of a memory usage concern.
public class CachedFilter extends Filter { BitSet bits; Filter filter;
public CachedFilter(Filter filter) { this.filter = filter; this.bits = null; }
public BitSet bits(IndexReader reader) throws IOException { if (bits != null) { return bits; }
bits = filter.bits(reader); return bits; } }
You would have problems if you searched a different index or different instance of IndexReader even with your caching here. You should cache like QueryFilter does to avoid a potential mismatch with IndexReader instances.
But you're implementation is exactly what I was envisioning with the added WeakHashMap of QueryFilter.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
