I have a Solr schema in which a field is declared as TrieFloatField:
<fieldType name="tfloat" class="solr.TrieFloatField" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
(...)
<field
name="someField"
type="tfloat"
indexed="true"
stored="false"
multiValued="false" />
If I use it to sort the results like so:
solrQuery.addSortField("someField", ORDER.asc);
solrQuery.addSortField("score", ORDER.desc);
The float numbers are not returned in correct numerical order, i.e.: I’d get results such as :
0.31 0.67 0.80 15.13 0.09 15.13 0.04
What’s even stranger is that when I use this field to sort my results, some sorting DOES happen (they’re in a different order that if, let’s say, I don’t use any sort field at all). Also, even if I change the sort order from asc to desc, the results are in the same order.
I thought that the TrieFloat type would work well for this. However I now see in the docs that they only mention that it’s “Floating point field accessible Lucene TrieRange processing”:
http://lucene.apache.org/solr/api-4_0_0-ALPHA/org/apache/solr/schema/TrieFloatField.html
and I honestly don’t really know what that means. I also see that there’s a SortableFloatField:
but the docs don’t really say anything about how it behaves when being used as a sort criteria.
My question simply is: which one of those two types (or what other type) is good for storing float numbers such that they can be used for proper (natural) ascending and descending sorting in a Solr query
Both classes should work, but
TrieFloatFieldwill require much less memory thanSortableDoubleField(given that the former uses a float field cache while the latter uses a String field cache). Note that if you don’t need to perform range queries, you should setprecisionStep=0.However the bug you hit is very strange…