lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Commented: (SOLR-1334) SortableXXXField could use native FieldCache for sorting
Date Wed, 05 Aug 2009 08:40:15 GMT


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:
>             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.

View raw message