lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: missing type check when working with pint field type
Date Tue, 18 Jan 2011 13:38:57 GMT
I suspect you missed this comment in the schema file:
***
Plain numeric field types that store and index the text
      value verbatim (and hence don't support range queries, since the
      lexicographic ordering isn't equal to the numeric ordering)
***

So what's happening is that the field is being indexed as a text type and, I
suspect,
begin tokenized. The error you're getting is when trying to sort against a
tokenized
field which is undefined. At least that's my story and I'm sticking to
it....

Best
Erick

On Tue, Jan 18, 2011 at 8:10 AM, Sascha Szott <szott@zib.de> wrote:

> Hi folks,
>
> I've noticed an unexpected behavior while working with the various built-in
> integer field types (int, tint, pint). It seems as the first two ones are
> subject to type checking, while the latter one is not.
>
> I'll give you an example based on the example schema that is shipped out
> with Solr. When trying to index the document
>
> <doc>
>  <field name="id">1</field>
>  <field name="foo_i">invalid_value</field>
>  <field name="foo_ti">1</field>
>  <field name="foo_pi">1</field>
> </doc>
>
> Solr responds with a NumberFormatException (the same holds when setting the
> value of foo_ti to "invalid_value"):
>
> java.lang.NumberFormatException: For input string: "invalid_value"
>
> Surprisingly, an attempt to index the document
>
> <doc>
>  <field name="id">1</field>
>  <field name="foo_i">1</field>
>  <field name="foo_ti">1</field>
>  <field name="foo_pi">invalid_value</field>
> </doc>
>
> is successful. In the end, sorting on foo_pi leads to an exception, e.g.,
> http://localhost:8983/solr/select?q=*:*&sort=foo_pi desc
>
> raises an HTTP 500 error:
>
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>        at java.lang.String.charAt(String.java:686)
>        at
> org.apache.lucene.search.FieldCache$7.parseInt(FieldCache.java:234)
>        at
> org.apache.lucene.search.FieldCacheImpl$IntCache.createValue(FieldCacheImpl.java:457)
>        at
> org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:224)
>        at
> org.apache.lucene.search.FieldCacheImpl.getInts(FieldCacheImpl.java:430)
>        at
> org.apache.lucene.search.FieldCacheImpl$IntCache.createValue(FieldCacheImpl.java:447)
>        at
> org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:224)
>        at
> org.apache.lucene.search.FieldCacheImpl.getInts(FieldCacheImpl.java:430)
>        at
> org.apache.lucene.search.FieldComparator$IntComparator.setNextReader(FieldComparator.java:332)
>        at
> org.apache.lucene.search.TopFieldCollector$OneComparatorNonScoringCollector.setNextReader(TopFieldCollector.java:94)
>        at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:249)
>        at org.apache.lucene.search.Searcher.search(Searcher.java:171)
>        at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:988)
>        at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:884)
>        at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341)
>        at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:182)
>        at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
>        at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
>        at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
>        at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
>        at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> [...]
>
>
> Is this a bug or did I missed something?
>
> -Sascha
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message