You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Yonik Seeley (JIRA)" <ji...@apache.org> on 2009/08/05 00:10:14 UTC

[jira] Commented: (SOLR-1334) SortableXXXField could use native FieldCache for sorting

    [ https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739205#action_12739205 ] 

Yonik Seeley commented on SOLR-1334:
------------------------------------

Yeah - I decided against upgrading the Sortable* field types because it wouldn't be 100% back compatible, and we have the Trie* fields now anyway.  The issue has to do with missing values - if you use native FieldCache entries, you can't tell when a document had a value or not and that breaks some stuff like StatisticsComponent, and SortMissingLastComparator.

> SortableXXXField could use native FieldCache for sorting
> --------------------------------------------------------
>
>                 Key: SOLR-1334
>                 URL: https://issues.apache.org/jira/browse/SOLR-1334
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Uwe Schindler
>
> When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields.
> The same parsers could be used to create ValueSources for these types.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.