You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erik Hatcher <er...@ehatchersolutions.com> on 2003/09/15 19:58:18 UTC
Re: Caching filter wrapper
On Monday, September 15, 2003, at 12:46 PM, Bruce Ritchie wrote:
> Erik Hatcher wrote:
>> So, if there was a caching filter implemented like yours, but with
>> the WeakHashMap cache like QueryFilter, would you use it instead of
>> what you've done?
>
> I think it would depend on whether the cache key's are independant of
> IndexReaders (i.e. an implementation that's not implemented in the
> same manner as the QueryFilter by using an IndexReader as a cache key
> (or part thereof). This is because I open multiple IndexReaders
> against a single index which would cause (false) cache misses. If that
> wasn't the case then I think I'd be ok with using it, irregardless of
> my preference to use our own cache architecture. I'd definitely use it
> if I could provide the backing map via a setMap() method or the like.
Cool.... I'll work on adding an implementation then. But what would be
the key to the map if not the IndexReader instance? It ought to be
something related to that at least for the scenario's where a single
filter instance is being used over multiple indices. Or would simply
two different constructors be enough (one taking a Filter and
defaulting to a WeakHashMap, and the other taking a Filter and a Map to
use), and still use IndexReader as the key?
Erik
Re: Caching filter wrapper
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I've added the proposed CachingWrapperFilter using QueryFilter's method
of caching along with the fix Otis put in this morning to avoid an NPE
when using remote searching.
See the @todo's there to see if there is more work to be done. Using
QueryFilter or this caching one through remote searcher will void any
caching - is this of concern here? Do we need to provide a
user-definable Map implementation for the cache store as an option?
I'll write up some javadocs for this once we've ironed out the
implementation.
Erik
On Tuesday, September 16, 2003, at 03:28 PM, Bruce Ritchie wrote:
> Erik Hatcher wrote:
>> Cool.... I'll work on adding an implementation then. But what would
>> be the key to the map if not the IndexReader instance? It ought to
>> be something related to that at least for the scenario's where a
>> single filter instance is being used over multiple indices. Or would
>> simply two different constructors be enough (one taking a Filter and
>> defaulting to a WeakHashMap, and the other taking a Filter and a Map
>> to use), and still use IndexReader as the key?
>
> Well, seeing as how things are resolving on the other half of this
> thread, I'll take back my concern about tying the caching to a reader
> instance (since I've come up with a decent solution which will allow
> me to use a single reader).
>
>
> Regards,
>
> Bruce Ritchie
> <smime.p7s>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: Caching filter wrapper
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I've added the proposed CachingWrapperFilter using QueryFilter's method
of caching along with the fix Otis put in this morning to avoid an NPE
when using remote searching.
See the @todo's there to see if there is more work to be done. Using
QueryFilter or this caching one through remote searcher will void any
caching - is this of concern here? Do we need to provide a
user-definable Map implementation for the cache store as an option?
I'll write up some javadocs for this once we've ironed out the
implementation.
Erik
On Tuesday, September 16, 2003, at 03:28 PM, Bruce Ritchie wrote:
> Erik Hatcher wrote:
>> Cool.... I'll work on adding an implementation then. But what would
>> be the key to the map if not the IndexReader instance? It ought to
>> be something related to that at least for the scenario's where a
>> single filter instance is being used over multiple indices. Or would
>> simply two different constructors be enough (one taking a Filter and
>> defaulting to a WeakHashMap, and the other taking a Filter and a Map
>> to use), and still use IndexReader as the key?
>
> Well, seeing as how things are resolving on the other half of this
> thread, I'll take back my concern about tying the caching to a reader
> instance (since I've come up with a decent solution which will allow
> me to use a single reader).
>
>
> Regards,
>
> Bruce Ritchie
> <smime.p7s>
Re: Caching filter wrapper
Posted by Bruce Ritchie <br...@jivesoftware.com>.
Erik Hatcher wrote:
> Cool.... I'll work on adding an implementation then. But what would be
> the key to the map if not the IndexReader instance? It ought to be
> something related to that at least for the scenario's where a single
> filter instance is being used over multiple indices. Or would simply
> two different constructors be enough (one taking a Filter and defaulting
> to a WeakHashMap, and the other taking a Filter and a Map to use), and
> still use IndexReader as the key?
Well, seeing as how things are resolving on the other half of this thread, I'll take back my concern
about tying the caching to a reader instance (since I've come up with a decent solution which will
allow me to use a single reader).
Regards,
Bruce Ritchie