Robo 3T 1.1 - Big float numbers are showing incorrectly

[jimblind]

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.

[patrick-webs]

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]

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.

[patrick-webs]

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]

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]

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]

@simsekgokhan Any news on this?