See also SOLR-6364 and the suggestion there to jave an optional
"json.long=[num|text]" param for clients that want solr to return longs as
a quoted string values rather then as raw JSON numbers...
https://issues.apache.org/jira/browse/SOLR-6364
...would probably be fairly trivial to implement
On Wed, Nov 26, 2014 at 10:38 PM, Alexandre Rafalovitch
wrote:
> Looks like one of these:
> http://stackoverflow.com/questions/1379934/large-numbers-erroneously-rounded-in-javascript
Yeah, that's what Brendan pointed to earlier in this thread.
> In the UI code, we just seem to be using JSON obje
Looks like one of these:
http://stackoverflow.com/questions/1379934/large-numbers-erroneously-rounded-in-javascript
In the UI code, we just seem to be using JSON object's native functions.
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newsletter: http:
I was using the SOLR administrative interface to issue my queries. When I
bypass the administrative interface and go directly to SOLR, the JSON return
indicates the AID is as it should be. The issue is in the presentation layer of
the Solr Admin UI. Which is good news.
Thanks all, my bad. Shoul
Yeah, XML was fine, JSON outside admin was fine... it's definitely
just the client (admin).
Oh, you meant the JSON formatting code in the client - yeah.
Hopefully there is a way to fix it w/o sacrificing our nice syntax
highlighting.
-Yonik
http://heliosearch.org - native code faceting, facet func
Sounds like a JSON formatting code then? What happens when the return
format is XML?
Also, what happens if the request is made with browser debug panel
open and we can compare what is on the wire with what is in the
browser?
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
On Wed, Nov 26, 2014 at 7:57 PM, Brendan Humphreys wrote:
> 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
Ah, indeed - I was testing direc
On Wed, Nov 26, 2014 at 7:30 PM, Erick Erickson wrote:
> Hmmm, this seems to be browser related
> because if I use curl or Safari, the return and display
> are fine.
>
> i.e.
> curl http://localhost:8983/solr/collection1/query?q=*:*
>
> displays:
>
> "eoe_tl":20140716126615472,
> "
> >> eoe_s: "20140716126615472",
> >>
> >> eoe_tl: 20140716126615470,
> >> eoe_s: "20140716126615474",
> >>
> >> eoe_tl: 20140716126615476,
> >> eoe_s: "20140716126615476",
> >>
> >> No, that
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
>> wrote:
>>> Your query has a space in it after the colon, which is not valid. Could you
>>> p
nsky
> 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
&
e:
>> 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: We
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 stor
Subject: TrieLongField not store large longs correctly
I believe I have encountered a bug in SOLR. I have a data type defined as
follows:
positionIncrementGap="0”/>
And I have a field defined like so:
multiValued="false" required="true" omitNorms="true"
I believe I have encountered a bug in SOLR. I have a data type defined as
follows:
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 e
15 matches
Mail list logo