[
https://issues.apache.org/jira/browse/LUCENE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654068#action_12654068
]
Michael McCandless commented on LUCENE-1478:
--------------------------------------------
bq. The problem is, that the comparator for byte fields returned SortField.INT
in sortType() instead of SortField.BYTE.
Whoa, nice catch! I think it's fine to include the fix here (it was not
manifesting as a bug w/o your changes).
bq. The patch also provides a test case in "TestSort" that uses a custom
parser, that maps a simple char value from 'A' to 'J' to a byte, short, int,
long, float, double with some crazy algorithm to test sorting.
Awesome, I like the new test!
bq. Additionally the new SortField constructor checks the sort type and
corresponding parser for consistency and throws IllegalArgumentException, if
not correct
I like this stronger typing. Could you change the message thrown exception to
detail the type that was given and what parser was provided (better
transparency)?
bq. SortField could have separate constructors for each parser type without
type parameter
That is a good idea, I think. The two args are redundant & therefore a source
of confusion/error. It is annoying how we keep having to "multiply by N" so
many places in Lucene that want to switch on the different builtin types
(LUCENE-831 has this too).
bq. Changing this would require some more work in the FieldSortedHitQueue, as
copying the SortField would require more work
Can we just SortField.clone() instead of "new SortField(lots-of-tricky-args)"
in FieldSortedHitQueue?
bq. this patch also extends contrib's TrieUtils and test cases to support a
static trie-tolong/double-parser and a SortField factory to handle trie-encoded
fields very simple using the long fieldcache
Great!
> 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
> Attachments: LUCENE-1478-no-superinterface.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
