-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Integer schemas silently change the value of large ints, overflow to negative values #2378
Comments
Just like #2377 , this is due to JSON parsing in Go. To deal well with huge integers, the recommended way would be to set the int schema, and then send data as hex encoded strings via JSON. Or, use RDFs. Case in point: https://play.golang.org/p/rdh0UbgsDlM |
So, a bit of backstory, @aphyr went and posted this on Twitter after my comments here: https://twitter.com/aphyr/status/997148938028318720. And found that there's thing called json.Number -- which I didn't know about. So, it looks like by using Json.Number, we might be able to correctly tell if it's an int64 or a float64. I'll work on implementing that today, to see if we can now correctly parse numbers. This is the Go Play code, which can correctly determine int64 vs float64: |
Tested this with the above change. Works. |
Dgraph's tour explains that the int schema is a 64-bit signed integer. However, on Dgraph 5b93fb4,
int
attributes have some strange behavior that suggests mayyyybe it's being converted to a floating-point intermediate representation. For instance, here's a table of values written to dgraph, followed by that same value as it is read back:Notice that numbers above 9007199254740992N--2^53+1--are not exactly representable, and are remapped to numbers that would fit in an IEEE 754 double precision float. I think this behavior also interacts with a later coercion to signed ints, because...
Numbers above 9223372036854775296 are pinned to -9223372036854775809, which is -2^63. I thiiiink what's happening here is that the floating-point coercion is pushing these values up to 2^64, which causes an unchecked signed integer overflow, and wraps over to -2^63.
You can reproduce this with 56dce4d5b875bc2eec841564f865b72168c91938 by running
The text was updated successfully, but these errors were encountered: