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,
> "
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
wrote:
> Yep, see my second e-m
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 wrote:
> On Wed, Nov 26, 2014 at 7:10 PM, Erick Erickson
> wrote:
>> This is very weird, someone want to check this out to insure that I'm
>> not hallucinating?
>
> I ju
On Wed, Nov 26, 2014 at 7:10 PM, Erick Erickson 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 cl
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":20140716126615474,
"e
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=
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
S
14 matches
Mail list logo