[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086258#comment-13086258
]
Michael McCandless commented on LUCENE-3360:
--------------------------------------------
I actually prefer the name AtomicFieldCache, since this matches other
places (eg. AtomicReaderContext), and because it's not necessarily a
segment (SlowMultiReaderWrapper returns an instance).
The name SegmentFieldCacheImpl seems OK, but can't this class be
package private?
I love the name InsaneFieldCache!
For the new IR.getFieldCache() instead of a "generic" UOE can we throw
something like MR.fields() throws? Ie the exc message should explain
that you should use the SlowMRWrapper instead.
I'm nervous about how the [deprecated] FC makes a new SlowMRWrapper()
for each getXXX call -- I think this class uses "this" as the
getFieldCacheKey? Won't this mean each lookup will build a new cache
entry? (Hmm... but then why don't tests fail... I think we have at
least one test verifying same instance is returned for 2 calls in a
row).
> 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
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
