Hi Dgraph team, pretty new to Dgraph so excuse my potential incomprehensions.
Experience Report
I had a discussion with @pawanrawal on Slack over a efficient way to support 64 bits integer via the GraphQL endpoint, which isn’t standard since the only “Int” type supported is 32 bits.
Storing it as a string would have been an option but I need to be able to index with this integer, and do simple operations like ascending / descending sorting or value comparisons, which is something impossible with a string.
What you wanted to do
As you did with DateTime or even ID, storing a “custom type” could be done too, by returning an hex-coded string representing the 64 bits value as suggested Pawan, and still allow us to store the value efficiently and do database operations on it.
Using Javascript’s standard way of returning BigInt could be done too, by suffixing the value with n
Yeah, this shouldn’t be hard. We didn’t prioritize it as we didn’t have a lot of users asking for this. Let me get this prioritized, it should be an easy addition.
Yeah, we can have a custom scalar for Int64 and achieve this like we already do for DateTime.
Nope, that was BigFloat. Dgraph already supports int64 (https://dgraph.io/docs/query-language/#schema-types). That is int in GraphQL± maps to an int64 whereas int in GraphQL maps to int32 because the spec specifies that. We just have to support 64 bit integers in GraphQL.