[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-tabpanelfocusedCommentId=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
HashMapEntryT,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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=13114343#comment-13114343
]
Martijn van Groningen edited comment on LUCENE-3360 at 9/25/11 8:06 PM:
Attached an updated version for trunk.
* FieldCache and FieldCacheImpl have been removed completely from the source
code.
* DocTerms and DocTermsIndex have been moved to o.a.l.search.cache
* Parsers have been moved to o.a.l.search.cache.parser
* Functionality that relies on top level caches (e.g. faceting and some
functions) now uses SlowMultiReaderWrapper: {code}new
SlowMultiReaderWrapper(topReader).getFieldCache(){code}
was (Author: martijn.v.groningen):
Attached an updated version for trunk.
* FieldCache and FieldCacheImpl have been removed completely from the source
code.
* DocTerms and DocTermsIndex have been moved to o.a.l.search.cache
* Parsers have been moved to o.a.l.search.cache.parser
* Functionality that relies on top level caches (e.g. faceting and some
functions) now uses SlowMultiReaderWrapper: {code}new
SlowMultiReaderWrapper(topReader)).getFieldCache(){code}
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.5, 4.0
Attachments: 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
HashMapEntryT,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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=13114375#comment-13114375
]
Martijn van Groningen edited comment on LUCENE-3360 at 9/25/11 9:45 PM:
Makes sense to wait to commit this change for trunk. I've updated the 3x
version of the patch with latest changes in 3x. This version only deprecates FC.
was (Author: martijn.v.groningen):
Makes sense to wait committing for trunk. I've updated the 3x version of
the patch with latest changes in 3x. This version only deprecates FC.
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.5, 4.0
Attachments: 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
HashMapEntryT,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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=13086571#comment-13086571
]
Martijn van Groningen edited comment on LUCENE-3360 at 8/17/11 8:33 PM:
Added a new version of patch.
* Renamed SegmentFieldCache to AtomicFieldCache.
* SegementFieldCacheImpl is now package protected. This class has been moved to
lucene.index package.
* Added TestSegmentFieldCacheImpl test.
was (Author: martijn.v.groningen):
Add new version of patch.
* Renamed SegmentFieldCache to AtomicFieldCache.
* SegementFieldCacheImpl is now package protected. This class has been moved to
lucene.index package.
* Added TestSegmentFieldCacheImpl test.
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.4, 4.0
Attachments: 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
HashMapEntryT,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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
