[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698394#action_12698394
]
Michael McCandless commented on LUCENE-831:
-------------------------------------------
bq. Also, this early, I know you'll have me changing directions fast enough
that I'm still in pretty rough hammer out mode.
Yeah I hear you ;) Things're fast moving... I'm glad you're good with
The Eclipse.
bq. Do we need Uninverter if overriding getXXX is easy enough and we pass the
ValueSource on SortField?
Good question... though it is nice/important to not have to implement
your own TermEnum/TermDocs iteration logic.
bq. Being able to change the ValueSource on the fly now with SortField has
implications for CachingValueSource.
I think an app would need to pay attention here, ie, if caching is
needed the app should always pass the same CachingValueSource to all
sort fields. It's up to the app to scope their ValueSources
correctly. You're right that if you have a bug and don't always use a
consistent CachingValueSource, you can use too much RAM since a given
field's int[] can be double cached; but I think that's a bug in the
app? It's analogous to using 2 IndexReaders instead of sharing?
Though... I'm not sure. Something's not yet right about our approach
but I can't think of how to fix it... will mull it over.
I wonder if we can somehow fit norms handling into this? Norms ought
to be some sort of XXX.getBytes() somewhere, but I'm not sure how
yet. It's tricky because norms accept changes and thus must implement
copy-on-write. So maybe we levae them out for now...
> 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
> Assignee: Mark Miller
> Fix For: 3.0
>
> Attachments: ExtendedDocument.java, fieldcache-overhaul.032208.diff,
> fieldcache-overhaul.diff, fieldcache-overhaul.diff,
> LUCENE-831-trieimpl.patch, 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, 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
