On Wed, Nov 26, 2014 at 7:10 PM, Erick Erickson <erickerick...@gmail.com> wrote:
> This is very weird, someone want to check this out to insure that I'm
> not hallucinating?

I just tried the following in Heliosearch, since I had it open (based
on 4.10.x):

  @Test
  public void testWeird() throws Exception {
    Client client = Client.localClient;
    long val = 20140716126615474L;
    client.add(sdoc("id", "1", "foo_tl",val), null);
    client.commit();
    // straight query facets
    client.testJQ(params("q", "id:1")
        , "response/docs/[0]/foo_tl==" + val
    );
  }

Seemed to work fine - no bug.
How did you index the docs? Maybe it's a client issue or something...

-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data


> Because it looks like a JIRA to me.
>
> I tried this with 4.8.0 (because I had it handy) and 5x, same
> results
>
> Indexed three docs with eoe_tl and eoe_s pairs:
> eoe_tl is a tlong
> eoe_s is a string
>
> doc1 has
> eoe_tl=20140716126615472
> eoe_s=20140716126615472
>
> doc2 has
> eoe_tl=20140716126615474
> eoe_s=20140716126615474
>
> doc3 has
> eoe_tl=20140716126615476
> eoe_s=20140716126615476
>
>
> Now, I can search on these perfectly fine, I get
> 0 hits for eoe_tl: 20140716126615470
>
> and 1 hit for
> eoe_tl: 20140716126615472
>
> one hit for:
> eoe_tl:20140716126615474
>
> and one hit for
> eoe_tl:20140716126615476
>
> BUT, the display when q=*:* is:
>
> eoe_tl: 20140716126615470,
> eoe_s: "20140716126615472",
>
> eoe_tl: 20140716126615470,
> eoe_s: "20140716126615474",
>
> eoe_tl: 20140716126615476,
> eoe_s: "20140716126615476",
>
> No, that's not a typo, the number ending in 6 is displayed correctly
> but the first two tlongs end in 0.
>
> We're nowhere near overflow with this number.....
>
> On Wed, Nov 26, 2014 at 3:27 PM, Jack Krupansky <j...@basetechnology.com> 
> wrote:
>> Your query has a space in it after the colon, which is not valid. Could you
>> post the actual, full query request, as well as the full query response?
>>
>> -- Jack Krupansky
>>
>> -----Original Message----- From: Thomas L. Redman
>> Sent: Wednesday, November 26, 2014 2:45 PM
>> To: solr-user@lucene.apache.org
>> Subject: TrieLongField not store large longs correctly
>>
>>
>> I believe I have encountered a bug in SOLR. I have a data type defined as
>> follows:
>>
>> <fieldType name="long" class="solr.TrieLongField" precisionStep="0"
>> positionIncrementGap="0”/>
>>
>> And I have a field defined like so:
>>
>> <field name="aid" type="long" indexed="true" stored="true"
>> multiValued="false" required="true" omitNorms="true" />
>>
>> I have not been able to reproduce this problem for smaller numbers, but for
>> some of the very large numbers, the value that gets stored for this “aid”
>> field is not the same as the number that gets indexed. For example,
>> 20140716126615474 is stored as 20140716126615470, or in any even, that is
>> the way it is getting reported back. When I issue a query, “aid:
>> 20140716126615474”, the value reported back for aid is 20140716126615470!
>>
>> Any suggestions?=

Reply via email to