[
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-no-superinterface.patch
Attached is a patch that implements the first variant (without super interface
for all FieldParsers). All current tests pass. A special test case for a custum
field parser was not implemented.
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)].
A good test case would be to store some dates in ISO format in a field and then
sort it as longs after parsing using SimpleDateFormat. This would be another
typical use case (sorting by date, but not using SortField.STRING to minimize
memory usage).
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)
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
