[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698264#action_12698264
]
Mark Miller commented on LUCENE-831:
------------------------------------
bq. How about SortField taking ValueSource?
Right - theres the right thought I think. I'll play with that.
bq. Need to pass in ValueSource impl to IndexReader.open, defaulting to
Cached(Uninverted)
Yes - only havn't because that code is kind of unfirm - it already seems like
it will prob be moved out to SortField :) So I was just short-cut initing it.
bq. Should CachingValueSource really include IndexReader in its key?
Probably not then :) I'll be going over that tighter - I was in speed mode and
havn't considered the CachingValueSource much yet - I kind of just banged out a
quick impl (gotto love eclipses generate hashcode/equals), put it in and tested
it. To handle all of this 'do it for Long, repeat for Int, repeat for Byte,
etc' I go somewhat into robot mode. Also, this early, I know you'll have me
changing directions fast enough that I'm still in pretty rough hammer out mode.
bq. Why do we need to define StringInverter, IntInverter, etc in
UninversionValueSource?
Yes true. I was using anon classes in the prev patch, but upon switch to
Uninverter, I just did mostly what came to mind quickest looking at your
example code and what I had.
Indeed, overriding getXXX is simple and effective. As I think about it - now I
am thinking I did it for the getArray call to return the right type (easy with
anon class, but custom passed Uninverter ?). Could return object and cast
though ...
Do we need Uninverter if overriding getXXX is easy enough and we pass the
ValueSource on SortField?
bq. Should we deprecate function.FieldCacheSource,
Yeah for sure. I'll take a closer look at the function package soon. Thus far,
I've just got it compiling and the main sort tests passing. As soon as I feel
the API is firming (which, sweet, it already is a bit I think), I'll start
polishing and filling in the missing pieces, more thorough nocommits, comments.
> 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.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
>
>
> 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
