On Monday, September 15, 2003, at 09:45 AM, Bruce Ritchie wrote:
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.
Perhaps. I guess my point is that I would prefer a wrapper architecture for caching rather that having it built-in directly in the filters. Having it built-in would require me to rip it out when I upgraded our applications to the latest release. Implementing it as a wrapper allows me to bypass the caching built-in and decide what I want cached, how many I want cached and for how long (our caches can be size and time limited). Having it as a wrapper also allows other people to make the same sort of decisions as I require.
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.
Well, there's a part of the application that you're not seeing that does the checking of the index state. This is done inside of what is essentially a wrapper to a map which clears all filters upon a state change in the index. Your point is perfectly valid however for anyone who does not have such a wrapper and one that I should have mentioned in my previous email.
Regards,
Bruce Ritchie
smime.p7s
Description: S/MIME Cryptographic Signature
