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 Sat, 11 Apr 2009 21:29:14 GMT

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

Mark Miller edited comment on LUCENE-831 at 4/11/09 2:28 PM:
-------------------------------------------------------------

Any ideas on where parser fits in with valuesource? Its easy enough to kind of keep it how
it is, but then what if CSF can be stored as a byte rep of an int or something? parse(String)
won't make any sense. If we move Parser up to an Impl of valuesource, we have to special case
things -

Any thoughts? Just stick with allowing the passing of a 'String to type' Parser and worry
about possible byte handling later? A different parser object of some kind?

*edit*

I guess its not so bad if parser is still first class and something that read bytes would
just ignore the given parser? The parsing would just be built into something specialized like
that, and it would be free to ignore a given String parser?

      was (Author: markrmiller@gmail.com):
    Any ideas on where parser fits in with valuesource? Its easy enough to kind of keep it
how it is, but then what if CSF can be stored as a byte rep of an int or something? parse(String)
won't make any sense. If we move Parser up to an Impl of valuesource, we have to special case
things -

Any thoughts? Just stick with allowing the passing of a 'String to type' Parser and worry
about possible byte handling later? A different parser object of some kind?
  
> 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.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
>
>
> 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