I'd wager this is a loss of precision caused by Javascript rounding in the admin client. More details here:
http://stackoverflow.com/questions/1379934/large-numbers-erroneously-rounded-in-javascript Cheers, -Brendan On 27 November 2014 at 11:45, Erick Erickson <erickerick...@gmail.com> wrote: > 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?= >
