lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (LUCENE-831) Complete overhaul of FieldCache API/Implementation
Date Sat, 22 Mar 2008 23:37:25 GMT


Hoss Man commented on LUCENE-831:


I haven't looked at this issue or any of the code in my patch since my last updated, nor have
i had a chance to look at your updated patch, but a few comments...

1) you rock.

2) I have no idea what i had in mind for dealing with StringIndex when i said "a bit complicated,
but should be possible/efficient".  I do distinctly remember thinking that we should add support
for *just* getting the string indexes (ie: the current int[numDocs]) for when you don't care
what the strings are, just the sort order or *just* getting a String[numDocs] when you aren't
doing sorting and just want an "inverted inverted index" on the field ... but obviously we
still need to support the curent StringIndex (it's used in MultiSearcher right?)

> Complete overhaul of FieldCache API/Implementation
> --------------------------------------------------
>                 Key: LUCENE-831
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Hoss Man
>            Assignee: Michael Busch
>             Fix For: 2.4
>         Attachments: fieldcache-overhaul.032208.diff, fieldcache-overhaul.diff, fieldcache-overhaul.diff
> 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