: We have looked through the shards trying to find a value which is greater
: than radix 10 which would throw this exception. We did not find any. We have
Grant's guess doesn't make much sense to me ... it would explain why a
large short might appear that way, but not why a short short would
Hi. Thanks for the quick response.
We have looked through the shards trying to find a value which is greater
than radix 10 which would throw this exception. We did not find any. We have
values between 0 and 100 in that field. Would not SOLR complain if we tried
to index a non-short like for
More info from the registry.jsp page
Solr Specification Version: 1.4.0Solr Implementation Version: 1.4.0 833479 -
grantingersoll - 2009-11-06 12:33:40
Lucene Specification Version: 2.9.1
Lucene Implementation Version: 2.9.1 832363 - 2009-11-03 04:37:25
/M
On Mon, Feb 8, 2010 at 9:46 AM,
Hi.
When using the field type solr.ShortField in combination with sharding we
get results like this back:
str name=sentimentScorejava.lang.Short:40/str
Making it impossible to sort on that value.
Changing the field to IntegerField solves it.
Example search:
GET
In looking at the code, I see:
code
try {
short val = Short.parseShort(s);
writer.writeShort(name, val);
} catch (NumberFormatException e){
// can't parse - write out the contents as a string so nothing is lost and
// clients don't get a parse error.
