More of an update and work around. When you query a number field locally, it can return null. However, when you go through a shard if you have an empty number it throws an error.
Should I open a bug for this? On Thu, Aug 21, 2008 at 8:56 AM, Ian Connor <[EMAIL PROTECTED]> wrote: > I think I have narrowed it down to: > > <field name="impact_factor" type="integer" indexed="true" stored="true" /> > > where integer is defined in the example as: > > <fieldType name="integer" class="solr.IntField" omitNorms="true"/> > > It returns fine when I query directly, but blows up when going through > the binary conversion that shards uses. > > On Thu, Aug 21, 2008 at 8:37 AM, Ian Connor <[EMAIL PROTECTED]> wrote: >> Hi, >> >> What is the best way to figure out which field is giving this error: >> >> Aug 21, 2008 8:34:17 AM org.apache.solr.common.SolrException log >> SEVERE: java.lang.NumberFormatException: For input string: "" >> at >> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) >> at java.lang.Integer.parseInt(Integer.java:468) >> at java.lang.Integer.valueOf(Integer.java:553) >> at org.apache.solr.schema.IntField.toObject(IntField.java:71) >> at org.apache.solr.schema.IntField.toObject(IntField.java:32) >> >> It is confusing because if I run the same query without shards, it works. >> >> This fails: >> http://10.0.16.98:8983/solr/select?shards=10.0.16.98:8983/solr&q=cancer >> Where this works: >> http://10.0.16.98:8983/solr/select?q=cancer >> >> It seems limited to the binary transfer that happens between shards - >> where is the best place to start to debug this? I just updated from >> the latest trunk 1.3 >> >> -- > > -- > Regards, > > Ian Connor > -- Regards, Ian Connor
