This is very weird, someone want to check this out to insure that I'm not hallucinating?
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?=