lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shay Banon <kim...@gmail.com>
Subject Re: NRT and Caching based on IndexReader
Date Tue, 18 May 2010 01:12:25 GMT
Just saw that you opened a case for that. I think that its important in your
test case to also test for object identity, not just equals. This is because
the IndexReader (or the FieldCacheKey) are used as keys in weak hash maps,
which uses identity (==) equality for keys.

If FieldCacheKey is supposed to represent the key by which index readers
should be tested for "equality" (for example, it will be used in the
CachingWrapperFilter), and not the index reader itself, then I think it
should be renamed. What do you think? I am just looking now at what it does,
its new...

-shay.banon

On Tue, May 18, 2010 at 4:04 AM, Yonik Seeley <yonik@lucidimagination.com>wrote:

> On Mon, May 17, 2010 at 9:00 PM, Shay Banon <kimchy@gmail.com> wrote:
> > Great, so I am not imagining things this late into the night ... ;), not
> so
> > great, since using NRT with field cache (like sorting) or caching
> filters,
> > or anything that caches based on IndexReader not really an option. This
> > makes NRT very problematic to use in a real application.
>
> NRT is still pretty new :-)  And I do believe this is a bug, so we'll
> get it fixed.
> It's not actually a problem for FieldCache though - it no longer keys
> on the reader directly (if deleted docs are the only things that have
> changed, the FieldCache entry can still be shared).
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message