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 Thu, 19 Jul 2007 00:58:04 GMT


Hoss Man commented on LUCENE-831:

thanks for the feedback mark ... i honestly haven't looked at this patch since the last time
i updated the issue ... (i'm not sure if i've even thought about it once since then).  it's
the kind of things that seemed really cool important at the time, but then ... you know, other
things come up.

by all means, feel free to update it.

as i recall, the biggest thing about this patch that was really just pie in the sky and may
not make any sense is the whole concept of merging and letting subreaders of MultiReader do
their own caching which could then percolate up.  I did it on the assumption that it would
come in handy when reopening an IndexReader that contains several segments -- many of which
may not have changed since the last time you opened the index.  but i really didn't have any
idea how the whole reopening things would work.  i see now there is some reopen code in LUCENE-743,
but frankly i'm still not sure wether the API makes sense, or is total overkill.

it might be better to gut the merging logic from the patch and add it later if/when there
becomes a more real use case for it (the existing mergeData and isMergable methods could always
be re-added to the abstract base classes if it turns out they do make sense)

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