Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Date: Mon, 15 Sep 2003 10:27:27 -0400
Subject: Re: RE : DateFilter.Before/After
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Erik Hatcher <erik@ehatchersolutions.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F65C294.5030008@jivesoftware.com>
Message-Id: <BB3AB97E-E788-11D7-9CE9-000393A564E6@ehatchersolutions.com>

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.

> 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