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 16:42:26 GMT
These are legacy types that aren't, frankly, very useful in recent Solr. So
you can probably safely ignore them.

BTW, you probably want to go with Trie fields (tint, tfloat, etc) as a first
choice unless you have a definite reason not to.

Hope this helps
Erick

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

> 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<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
>>>
>>>
>>
> --
> Sascha Szott :: KOBV/ZIB :: <szott@zib.de> :: +49 30 84185-457
>

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