lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] Updated: (LUCENE-831) Complete overhaul of FieldCache API/Implementation
Date Thu, 04 Dec 2008 23:38:44 GMT


Mark Miller updated LUCENE-831:

    Attachment: LUCENE-831.patch

Updated to trunk.

I've combined all of the dual (primitive array/ObjectArray) CachKeys into one. Each cache
key can support both modes or throw UnsupportedException or something.

I've also tried something a bit experimental to allow users to eventually use custom or alternate
cachekeys (payload or sparse arrays or something) that work with internal sorting. A cache
implementation can now supply a ComparatorFactory (name will prob be tweaked) that handles
creating comparators. You can subclass ComparatorFactory and add new or override current supported

CustomComparators still needs to be twiddled with some.

I've converted some of the sort tests to run with both primitive and object arrays as well.

- Mark

> Complete overhaul of FieldCache API/Implementation
> --------------------------------------------------
>                 Key: LUCENE-831
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Hoss Man
>             Fix For: 3.0
>         Attachments: 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
> 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:
For additional commands, e-mail:

View raw message