lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-1478) Missing possibility to supply custom FieldParser when sorting search results
Date Mon, 08 Dec 2008 22:55:44 GMT

     [ 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-cleanup.patch

Hi Mike,
sorry, after looking a second time into the new SortField ctors, I chaged two cosmetic things:

- The ctor for parser assigns this.type=type and later calls the init method with the member
variable type. The init method assigns so the meber to the member agian. Cleaner is just call
the initFieldType() method in the correct instanceof clause hit.
- Moved the initFieldType() behind all ctors.

But this is only cosmetic :)

> 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


Mime
View raw message