lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LUCENE-831) Complete overhaul of FieldCache API/Implementation
Date Wed, 15 Apr 2009 12:17:15 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699166#action_12699166
] 

Mark Miller edited comment on LUCENE-831 at 4/15/09 5:16 AM:
-------------------------------------------------------------

Thinking a bit on this this morning:

I think that will work out right. We would have 3 different attacks at ValueSource.

1. A ValueSource per segment reader that handles all default ValueSource needs - you get it
with IndexReader.getValueSource. Its an UninversionValueSource wrapped by a CachingValueSource
by default.

2. A singleton back compat value source that is wrapped by CacheByReaderValueSource. It has
extra methods that takes Uninverters, allowing custom Uninverters and caching by Uninverter.

3. You can override the ValueSource used for Sorting by attaching it to the SortField. Likely,
you would wrap in a CacheByReaderValueSource and have your own singleton.

I think that gives us back compat and the best of both worlds?

      was (Author: markrmiller@gmail.com):
    Thinking a bit on this this morning:

I think that will work out right. We would have 3 different attacks at ValueSource.

1. A ValueSource per segment reader that handles all default ValueSource needs - you get it
with IndexReader.getValueSource. Its an UninversionValueSource wrapped by a CachingValueSource
by default.

2. A singleton back compat value source that is wrapped by CacheByReaderValueSource. It has
extra methods that takes Uninverters, allowing custom Uninverters and caching by Uninverter.

3. You can override the ValueSource used for Sorting by attaching it to the SortField. Likely,
you would weap in a CacheByReaderValueSource and have your own singleton.

I think that gives us back compat and the best of both worlds?
  
> 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, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message