-
Notifications
You must be signed in to change notification settings - Fork 163
BigInt columns should be GraphQLFloat #144
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
Comments
No firm opinion, any clues in the spec? |
Well the spec specifies that a GraphQLFloat is definitely a FP number-
However, the graphql-js implementation just uses parseFloat(ast.value) which in our case, passing a large integer value to parseFloat, results in standard integer, e.g. parseFloat("4121722835") // result: 4121722835
// not
// 4121722835.0 So in order to get a BigInt, it seems we have to use either a custom scalar type or use the Float type because of this behavior. I guess the "cleanest" way to do this would be to implement our own Scalar type called BigInt that doesn't adhere to the GraphQLInt limits. Then the question becomes whether this library starts implementing custom types. In this case, I am leaning towards the custom type as being the best solution... |
A custom scalar is probably the best way to go if there's no standard way of doing int8 |
The natural mapping would be to GraphQLString wouldn't it? If you need to further play with it on the GraphQL side you can convert to big-integer or float or whatever. My use case is that the BIGINT is a 64-bit integer unique iD, so I'm happy enough with the string representation on the GraphQL side. |
Yeah I agree with @brainjam after talking it over with Lee byron on the other projects. I will do a PR making GraphQLString the default. |
Wanted to get your thoughts on this issue we just ran into.
The graphql spec limits GraphQLInt values to 2^31.
However, we are converting BigInt columns to GraphQLInt, which silently returns those over 2^31 as
null
. Changing this type mapping to GraphQLFloat (which feels slightly wrong, since they are not floating point numbers) allows the numbers to be not-null (at least up to the JS limit of 2^53. Thoughts?The text was updated successfully, but these errors were encountered: