You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/02/23 14:07:48 UTC
[jira] [Issue Comment Edited] (LUCENE-3360) Move FieldCache to
IndexReader
[ https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214609#comment-13214609 ]
Uwe Schindler edited comment on LUCENE-3360 at 2/23/12 1:05 PM:
----------------------------------------------------------------
Hi,
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 impl of that, 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".
was (Author: thetaphi):
Hi,
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: https://issues.apache.org/jira/browse/LUCENE-3360
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org