Hi Erick,
I see the point. But what is pint (plong, pfloat, pdouble) actually
intended for (sorting is not possible, no type checking is performed)?
Seems to me as it is something very similar to the string type (both
store and index the value verbatim).
-Sascha
On 18.01.2011 14:38, Erick Erickson wrote:
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<sz...@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
--
Sascha Szott :: KOBV/ZIB :: <sz...@zib.de> :: +49 30 84185-457
