Have you tried reproducing the issue with the latest release?
Yes
What is the hardware spec (RAM, OS)?
Google Cloud VM
Steps to reproduce the issue (command/config used to run Dgraph).
I’m interfacing through the standard Dart library for value types and serialization (built_value) to serialize and store objects with fields of type DateTime. This library expects DateTime objects to be represented as integers. My schema defines these fields as integers and mutations to store values are accepted, but it looks from Ratel like they’re being interpreted by the DB as strings in at least some places. Query some data like the following:
{"id":"3ea20d96-3c1f-43dd-8f4d-4eb95bf51287","payload":{"message":"Error coercing value '1.5883164e+15' for field 'birthday' to type Int. (Locations: [{Line: 6, Column: 5}])"},"type":"error"}
When I change the schema to represent those fields as String, the data converts in Ratel…note the fields that had quotations no longer do. Once this happens, I don’t receive an error server-side but rather client-side in deserialization because the data is sent back as a string, even though it looks like an integer in Ratel. Mutations still work fine.
Hmmm, I thought these microseconds-since-epoch values fell well within range…? I’ve have no issue with these values in the other databases I’ve used.
Unless I’m very confused (which is possible), a Javascript BigInt library doesn’t do anything for me…and neither does switching schema to DateTime:
I’m using Dart, not JS…while I could build in custom serialization along the BigInt lines, it shouldn’t be necessary for another 250 years or so (~8e15 microseconds) given the calculation above and my experience with other DBs (SQL, Firestore).
The parsing error is on your side, not mine; Dart has no trouble with those numbers using standard types in the serialization library.
I suspect your DateTime format wants ISO8601 strings, whereas the standard dart serialization library uses micros since epoch. My serialized values simply don’t seem to save when using that type in schema.
It is not clear to me what or where the issue is. You mentioned Ratel, but your issue is on Dart lib? I’ll assume that your issue is just between Dgraph and Dart. The way that Ratel shows data isn’t important for us at all. It isn’t a way to debug something on the Dart side.
So, is your issue related to Dart being able to send big Integer to Dgraph, and when you request back that data the value is changed a bit or very different? Or Dgraph somehow gives you strings (on dart side) instead of the type defined on schema? That could be the client you are using, we don’t support dart, you are using a third-party client.
The DateTime type also won’t help here. We just support the mentioned ones on the above comments. Third-party ones you have to use normal Scalar types and deal on your side.
Where this error come from? Is it Dart or Dgraph? I mean, the dart client receives the request and throws the error? Or the Dart’s compiler is throwing it?
Let’s stop using Ratel as a debug tool for this. It is a way to visualize queries. You should use Dart’s debug tools ou curl to see what data is coming from Dgraph. I suspect that this might be something related to the size of the integer. There is an issue tracking this. Also, there is a “Big-Int” PR waiting to be reviewed for some time.
It is from @harshil_goel, hey Harshil can you help us to identify what is the cause of this issue? Thanks!
Unless it comes from a Dgraph’s error handling, it is coming from the client. And as I said before, maybe is the int size. Your client receives the int, but it is smaller than the needed. It can’t be the type of the key. In general Dgraph sends the exact type back to the user in JSON format.
BTW, are you serializing it right? Dart doesn’t infer JSON out of the box. You have to create a structure for it.
OK cool, thanks all for the range of info. I’ll stop lending credence to Ratel; I just found it curious and possibly related that quotation marks were on type int.
@MichelDiz just to answer your questions (sorry, I wasn’t very precise in a few places): I’m using my own custom Dart Dgraph client, which depends on the most popular Dart GQL and value type + serialization libraries. I was confident in serialization because that library is long-verified Google production code, very widely used in Dart+Flutter. That payload message is coming from Dgraph, and the object holding it is constructed in the Dart GQL lib.
@abhijit-kar@harshil_goel
Sounds like the answers. I’ll add a serialization plugin that coverts my values to either RFC 3339 or BigInt-style formats for now, and will adjust when I see that fix go live. Thanks both!
Hey @CosmicPangolin1
I just merged the PR which supports Int64 as a scalar type in GraphQL. Note that:
Int64 can currently represent values in range [-(2^53)+1, (2^53)-1] without any error.
Values out of this range but representable by a signed 64-bit integer, may get coercion error.
It is now available in master and would be part of release v20.11
Yep, just ran into this error and was trying to figure out the source myself. I was trying to store a phone number as a Int by stripping of the country code and removing any non numeric characters. What I soon realized is that my phone number is greater than 32 bit, lol. I’ll just have to use a string field until 20.11
I also struggled with this for quite some time as the latest docs identify int as supporting 64bit but that is not the case with Slash GraphQL service my backend is reporting v20.07.1-rc1
I spoke with the team, and they feel that this is something that will need a major upgrade to work. We’ll be likely going live with this fix at the end of this month
