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

["Michael McCandless (JIRA)" <ji...@apache.org>]

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

Michael McCandless commented on LUCENE-1478:
--------------------------------------------

Patch looks good, thanks Uwe!  Back compat looks preserved; while some
APIs (FieldSortedHitQueue.getCachedComparator) were changed, they are
package private.

Back-compat tests ("ant test-tag") pass as well.

bq. For testing, I modified one of my contrib TrieRangeQuery test cases locally to sort using a custom LongParser that decoded the encoded longs in the cache [parseLong(value) returns TrieUtils.trieCodedToLong(value)].

It looks like this didn't make it into the patch -- could you add it?

Actually, adding a core test case would also be good.  It could be
something silly, eg that parses ints but negates them, and then assert
that this yields the same result as the default IntParser with
reverse=true (assuming no ties).

bq. If you like my patch, we could also discuss about using a super-interface for all Parsers. The modifications are rather simple (only the SortField constructor would be affected and some casts, and of course: the superinterface in all declarations inside FieldCache, ExtendedFieldCache)

I agree, I would like to at least get some minimal static typing into
the API (Object is not ideal) even if it's simply a "marker" interface
If you're sure this can be done, such that all changes to
FieldCache/ExtendedFieldCache remain back compatibitle, then let's do
it?  And I think I do now agree: this can be done w/o breaking back
compat.  The only affected public methods should be your new SortField
methods, which is fine (no public methods take "Object parser" as far
as I can tell).


> 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
>         Attachments: LUCENE-1478-no-superinterface.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