lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan Humphreys <bren...@canva.com>
Subject Re: TrieLongField not store large longs correctly
Date Thu, 27 Nov 2014 00:57:54 GMT
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 <erickerickson@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 <yonik@heliosearch.com>
> wrote:
> > On Wed, Nov 26, 2014 at 7:10 PM, Erick Erickson <erickerickson@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 <
> jack@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?=
>

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