lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
Date Thu, 23 Feb 2012 13:05:49 GMT


Uwe Schindler commented on LUCENE-3360:

in my opinion, the whole FieldCache is obsolete somehow, since we have DocValues in trunk.
If we still want some "on-the-fly uninverting", we can simply expose that as another "DocValues"
impl. Why does FieldCache needs to be separate? DocValues is the API and FieldCache can simply
be another one not materialized on disk.

One cool thing about a separate "FieldCache DocValues" impl would be that you could merge...
Means: A 3.x index without DocValues could on the next merge be a 4.x segment with DocValues
that were merged on the fly from the 3.x index by uninverting :-) For trunk indexes we require
docvalues to facet, group, sort,... The 3.x codec would simply simulate that by doing uninversion.
Once those old 3.x segments are merged to new 4.x segments, docvalues materialize from the
"on-they-fly 3.x fieldcache docvalues".
> Move FieldCache to IndexReader
> ------------------------------
>                 Key: LUCENE-3360
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Martijn van Groningen
>             Fix For: 3.6, 4.0
>         Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch
> Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so that FieldCache
insanity caused by the WeakHashMap no longer occurs.
> * Add a new method to IndexReader that by default throws an UOE:
> {code}public FieldCache getFieldCache(){code}
> * The SegmentReader implements this method and returns its own internal FieldCache implementation.
This implementation just uses a HashMap<Entry<T>,Object>> to store entries.
> * The SlowMultiReaderWrapper implements this method as well and basically behaves the
same as the current FieldCacheImpl.
> This issue won't solve the insanity that comes from inconsistent usage of a single field
(for example retrieve both int[] and DocTermIndex for the same field). 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message