[
https://issues.apache.org/jira/browse/LUCENE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1478:
----------------------------------
Attachment: LUCENE-1478.patch
Here is the patch using the superinterface for all field parsers. 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.
Also fixed is the bug with the sortType() in comparator as mentioned before,
without this, the test case for bytes would not pass.
Additionally the new SortField constructor checks the sort type and
corresponding parser for consistency and throws IllegalArgumentException, if
not correct (e.g. using a LongParser with SortField.BYTE). During inventing
this patch I had another idea to fix the issue with not to have a new
super-interface: SortField could have separate constructors for each parser
type without type parameter (as type is forced by parser instance -- we could
also remove the type parameter in the current patch, as the type maybe set by
instanceof operator). Changing this would require some more work in the
FieldSortedHitQueue, as copying the SortField would require more work (but
could be fixed better as is is currently: a new SortField instance in the
constructor is only needed, if SortField.AUTO or CUSTOM was used, in all other
cases, the SortField instance can just be directly used).
Just give some comments!
> 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]
