[
https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739371#action_12739371
]
Uwe Schindler commented on SOLR-1334:
-------------------------------------
Ok, so it should stay as it is.
The problem with NULL values in the FieldCache is a pain, I had this problem
also in FieldCacheRangeFilter. Maybe in the complete overhaul task there should
be some OpenBitSet/DocIdSet in parallel to the native arrays, that marks all
valid values. E.g. it could be handled like a normal cache for a specific field
and could be retrieved by FieldCache.getValidValues() or something like that.
The bitset is build parallel to the uninversion. If the field name is the same,
the valid values are also the same (not related to data type).
What do you think?
> 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.
