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

Robert Newson commented on LUCENE-831:
--------------------------------------

This enhancement is particularly interesting to me (and the application my team 
is building). I'm not sure how much time I can donate but since I'd likely have 
to enhance this area of Lucene for our app anyway and it would be better to 
have it in core, I'd like to help out where I can.

The patch applies more or less cleanly against 2.4.0, but not trunk, btw. Is it 
possible to get the patch committed to a feature branch off of trunk perhaps?

Finally, I'm most interested in the ability to make disk-backed caches. A very 
quick attempt to put the cache into JDBM failed as the CacheKey classes are not 
Comparable, which seems necessary for most kinds of disk lookup structures. 
SimpleMapCache uses a HashMap, which just needs equals/hashcode methods.

The other benefit to this approach is that it allows the data structures needed 
for sorting to be reused for range filtering. My application needs both, though 
on numeric field types (dates predominantly).

Finally, this might also be a good time to add first class support for 
non-String field types. The formatting that NumberTools supplies is 
incompatible with SortField (the former outputs in base 36, the latter parses 
with parseLong), so there's clearly been several approaches to the general 
problem. In my case, I wrote a new Document class with addLong(name, value), 
etc.

> 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
>             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, 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]

Reply via email to