[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698254#action_12698254
]
Mark Miller edited comment on LUCENE-831 at 4/12/09 12:09 PM:
--------------------------------------------------------------
I began to make the switch of allowing an Uninverter to be attached to a
SortField (like Parser) with the idea of doing backcompat by wrapping the
Parser with an Uninverter. I caught myself though, because the reason I wasn't
doing that before is that Uninverter may not make sense for a given
ValueSource. By forcing you to set the Uninverters per type on the
UninversionValueSource instead (current posted patch), this issue is kind of
avoided - the possible problem is that it seems somewhat less dynamic in that
you set it once on the ValueSource and leave it instead of being able to pass
any impl any time on a SortField. Perhaps not so bad. But then how do I set the
Uninverter for back compat with an old Parser? It doesn't seem wise to allow
arbitrary Uninverter updates to the UninversionValueSource does it? Thread
safety issues, and ... but then how to handle back compat with the parser? ...
was (Author: [email protected]):
I began to make the switch of allowing an Uninverter to be attached to a
SortField (like Parser) with the idea of doing backcompat by wrapping the
Parser with an Inverter. I caught myself though, because the reason I wasn't
doing that before is that Inverter may not make sense for a given ValueSource.
By forcing you to set the inverters per type on the UninversionValueSource
instead (current posted patch), this issue is kind of avoided - the possible
problem is that it seems somewhat less dynamic in that you set it once on the
ValueSource and leave it instead of being able to pass any impl any time on a
SortField. Perhaps not so bad. But then how do I set the Uninverter for back
compat with an old Parser? It doesn't seem wise to allow arbitrary Uninverter
updates to the UninversionValueSource does it? Thread safety issues, and ...
but then how to handle back compat with the parser? ...
> 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: [email protected]
For additional commands, e-mail: [email protected]
