: 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
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, Marcu
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 exam
In looking at the code, I see:
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.
writer.writeStr(na
Hi.
When using the field type solr.ShortField in combination with sharding we
get results like this back:
java.lang.Short:40
Making it impossible to sort on that value.
Changing the field to IntegerField solves it.
Example search:
GET "
http://127.0.0.1:8110/solr/blogosphere-sv-2010Q1/select?q=