Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Robo 3T 1.1 - Big float numbers are showing incorrectly #1447

Open
jimblind opened this issue Oct 5, 2017 · 9 comments
Open

Robo 3T 1.1 - Big float numbers are showing incorrectly #1447

jimblind opened this issue Oct 5, 2017 · 9 comments
Assignees
Projects

Comments

@jimblind
Copy link

@jimblind jimblind commented Oct 5, 2017

In Robomongo 0.8.5 using query "db.getCollection('collectionname').find({})" got results:

{
    "_id" : 1505121011565746.000000,
    "email" : "test@testemail.com",
    "name" : "John"
}

We use float number type for IDs - in 0.8.5 version such numbers looks OK

In Robo 3T 1.1 for the same query results are:

{
    "_id" : 1.50512101156575e+15.0
    "email" : "test@testemail.com",
    "name" : "John"
}

Please help to get proper values for big float numbers in Robo 3T 1.1.

@jimblind jimblind changed the title Robo 3T 1.1 - Big floating numbers are showing incorrectly Robo 3T 1.1 - Big float numbers are showing incorrectly Oct 5, 2017
@patrick-webs
Copy link

@patrick-webs patrick-webs commented Nov 10, 2017

I am experiencing the same issue. As a result, the "Copy JSON" output is not considered valid for "Insert Document" which makes it difficult to move data from one collection to another.

As a workaround the following regular expression can be used on the output of copy JSON:

find: (\d+)\.(\d+[1-9])e\+(\d+)\.0
replace: $1$2.0

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Dec 7, 2017

Hi @jimblind, @patrick-webs, thanks for reporting the problem.
We plan to find a fix to this problem and include it in next release Robo 3T 1.2.

@patrick-webs
Can you give a concrete example for your problem?
Can be similar to @jimblind comment.

@simsekgokhan simsekgokhan self-assigned this Dec 7, 2017
@simsekgokhan simsekgokhan added this to Candidates in Robo 3T 1.2 Dec 7, 2017
@simsekgokhan simsekgokhan moved this from Candidates to In-progress in Robo 3T 1.2 Dec 7, 2017
@patrick-webs
Copy link

@patrick-webs patrick-webs commented Dec 7, 2017

Hi @simsekgokhan I think the problem I had was the exact same as reported by @jimblind , which is that when I do "Copy JSON" in Robo 3T I get a result like this:

{
    "_id" : ObjectId("5a21d0c62429ea3febffe394"),
    "foo" : {
        "bar" : {
            "1585620893902677" : {
                "a" : 1.58562089390268e+15.0,
                "b" : "abc",
                "c" : "def",
                "d" : 1
            },
        }
    }
}

note the value for the "a" key is not accepted as a valid JSON value for inserting back using the Insert Document feature of Robo 3T.

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Dec 11, 2017

Update:
Using Qt functions for parsing double solves some of current issues but now system has new problems due to an incorrect parsing by mongo::BSONElement::Double().

Next Actions

  • Investigate mongo::BSONElement::Double() or find another solution

Details:

  • Current problems (Robo 1.1):
    . 1505121011565750 is shown in scientific format as 1.50512101156575e+15.0
    . 1.0000000000000002 shown incorrectly as 1 (1.0000000000000002 is the smallest double-precision number > 1)
    . 1.005 shown correctly

  • Solution-1:
    . Using QString::number(...)
    . 1505121011565750 shown correctly
    . 1.0000000000000002 shown correctly
    . 1.005 shown not correctly as 1.0049999999999999 (Root cause: mongo function elem.Double() returns vlaue 1.005 incorrectly as 1.0049999999999999 (mongo::BSONElement::Double()) )

simsekgokhan added a commit that referenced this issue Dec 24, 2017
…oblems, incorrect value representation for 15 digit precision, -Infinity problem.
@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Dec 24, 2017

Update:
After improving the existing solution, most of the problems in this ticket and in #1155 seem to be resolved.
Only remaining problem is: "1.0000000000000002 (16 digit precision) shown incorrectly as 1. (1.0000000000000002 is the smallest double-precision number > 1)".

Next Actions

  • Solve the issue: "1.0000000000000002 (16 digit precision) shown incorrectly as 1"

Details:

  • Current problems (Robo 1.1):
    . "_id" : 1505121011565750 is shown in scientific format as "_id" : 1.50512101156575e+15.0
    . 1605131049382900 is shown in scientific format as 1.6051310493829e+15.0
    . 1.0000000000000002 (16 digit precision) shown incorrectly as 1. (1.0000000000000002 is the smallest double-precision number > 1)
    . 1.000000000000002 (15 digit precision) shown incorrectly as 1.
    . "-Infinity" is shown incorrectly as "Infinity" in text mode.
    . Infinity and -Infinity is shown as inf/-inf in tree/table mode.

  • Solved cases with the latest commit b48dc0b:
    . Using QString::number(...) for solution.
    . "_id" : 1505121011565750 shown correctly in decimal format (not in scientific format).
    . 1605131049382900 shown correctly in decimal format (not in scientific format).
    . 1.000000000000002 (15 digit precision) shown correctly .
    . "-Infinity" is shown correctly as "-Infinity" in text mode.
    . Infinity/-Infinity is shown correctly as Infinity /-Infinity in tree/table/text mode.

  • Remaining problems after the latest commit b48dc0b:
    . 1.0000000000000002 (16 digit precision) shown incorrectly as 1. (1.0000000000000002 is the smallest double-precision number > 1)

@arboleya
Copy link

@arboleya arboleya commented Nov 5, 2018

@simsekgokhan Any news on this?

@lacivert
Copy link

@lacivert lacivert commented Mar 7, 2019

https://blog.robomongo.org/robo-3t-1-2/

This blog post says it is fixed, but the issue is still open?

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Mar 11, 2019

@arboleya , @lacivert
This is a very challenging task with lots of different corner cases. We already had some fixes and enhancements in version 1.2. See the list changes here in this section: https://blog.robomongo.org/robo-3t-1-2/#a1

Can you guys share if you have any problems?

@patrick-webs
Copy link

@patrick-webs patrick-webs commented Mar 11, 2019

FWIW, I think the issues I was having have been resolved in Robo 3T 1.2, my data set now properly outputs like

{
  "1626739542120169": {
    "id": 1626739542120169.0
  }
}

which is valid for insert. I think the issue is still open due to what was mentioned above "Remaining problems after the latest commit"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Robo 3T 1.2
In-progress
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants