[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697492#action_12697492
]
Michael McCandless commented on LUCENE-831:
-------------------------------------------
bq. Is there much difference in one massive array or an array of arrays? Its
just as much space and just as dangerous, right?
One massive array is far more dangerous during reopen() (ie that's why we did
LUCENE-1483) since it's non-incremental.
Array-per-segment I think is OK.
But yes both of them consume RAM, but I don't consider that "dangerous".
bq. I like the idea of an iterator API, but it seems we will still have to
provide random access with all its problems, right?
Right.
bq. Some apps will need random access to the field cache for any given document
right?
Yes but I think such apps should move to the per-segment model (eg a Filter's
getDocIdSet is called per segment reader).
If an app really wants to make a single massive array, they can certainly do
so, outside of Lucene.
bq. Allow a custom field cache loader for each type?
Yes, possibly w/ different degrees of extension (much like Collector). EG
maybe you just want to override how you parse an int, or maybe you want to take
control over the entire uninversion.
> Complete overhaul of FieldCache API/Implementation
> --------------------------------------------------
>
> Key: LUCENE-831
> URL: https://issues.apache.org/jira/browse/LUCENE-831
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Hoss Man
> Fix For: 3.0
>
> Attachments: ExtendedDocument.java, fieldcache-overhaul.032208.diff,
> fieldcache-overhaul.diff, fieldcache-overhaul.diff,
> LUCENE-831.03.28.2008.diff, LUCENE-831.03.30.2008.diff,
> LUCENE-831.03.31.2008.diff, LUCENE-831.patch, LUCENE-831.patch,
> LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch
>
>
> Motivation:
> 1) Complete overhaul the API/implementation of "FieldCache" type things...
> a) eliminate global static map keyed on IndexReader (thus
> eliminating synch block between completley independent IndexReaders)
> b) allow more customization of cache management (ie: use
> expiration/replacement strategies, disk backed caches, etc)
> c) allow people to define custom cache data logic (ie: custom
> parsers, complex datatypes, etc... anything tied to a reader)
> d) allow people to inspect what's in a cache (list of CacheKeys) for
> an IndexReader so a new IndexReader can be likewise warmed.
> e) Lend support for smarter cache management if/when
> IndexReader.reopen is added (merging of cached data from subReaders).
> 2) Provide backwards compatibility to support existing FieldCache API with
> the new implementation, so there is no redundent caching as client code
> migrades to new API.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
