[jira] Commented: (LUCENE-1478) Missing possibility to supply custom FieldParser when sorting search results

["Yonik Seeley (JIRA)" <ji...@apache.org>]

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

Yonik Seeley commented on LUCENE-1478:
--------------------------------------

I tracked down how this patch was causing Solr failures:

ExternalFileField in Solr maps from a uniqueKey to a float value from a separate file.
There is a cache that is essentially keyed by (IndexReader,field) that gives back a float[].

Any change in the index used to cause all values to be updated  (cache miss because the MultiReader was a different instance).  Now, since it's called segment-at-a-time, only new segments are reloaded from the file, leaving older segments with stale values.

It's certainly in the very gray area... but perhaps Solr won't be the only one affected by this - maybe apps that implement security filters, etc?

> Missing possibility to supply custom FieldParser when sorting search results
> ----------------------------------------------------------------------------
>
>                 Key: LUCENE-1478
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1478
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.4
>            Reporter: Uwe Schindler
>            Assignee: Michael McCandless
>             Fix For: 2.9
>
>         Attachments: LUCENE-1478-cleanup.patch, LUCENE-1478-no-superinterface.patch, LUCENE-1478.patch, LUCENE-1478.patch, LUCENE-1478.patch, LUCENE-1478.patch, LUCENE-1478.patch
>
>
> When implementing the new TrieRangeQuery for contrib (LUCENE-1470), I was confronted by the problem that the special trie-encoded values (which are longs in a special encoding) cannot be sorted by Searcher.search() and SortField. The problem is: If you use SortField.LONG, you get NumberFormatExceptions. The trie encoded values may be sorted using SortField.String (as the encoding is in such a way, that they are sortable as Strings), but this is very memory ineffective.
> ExtendedFieldCache gives the possibility to specify a custom LongParser when retrieving the cached values. But you cannot use this during searching, because there is no possibility to supply this custom LongParser to the SortField.
> I propose a change in the sort classes:
> Include a pointer to the parser instance to be used in SortField (if not given use the default). My idea is to create a SortField using a new constructor
> {code}SortField(String field, int type, Object parser, boolean reverse){code}
> The parser is "object" because all current parsers have no super-interface. The ideal solution would be to have:
> {code}SortField(String field, int type, FieldCache.Parser parser, boolean reverse){code}
> and FieldCache.Parser is a super-interface (just empty, more like a marker-interface) of all other parsers (like LongParser...). The sort implementation then must be changed to respect the given parser (if not NULL), else use the default FieldCache.getXXXX without parser.

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