Yep, see my second e-mail. I tried a unit test too and couldn't get it to fail.
On Wed, Nov 26, 2014 at 4:34 PM, Yonik Seeley <yo...@heliosearch.com> wrote:
> 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?=
