Directive or something to force to use a Long?

[marceloverdijk]

Having this schema part:

type PageInfo {

    hasNextPage: Boolean!
    hasPreviousPage: Boolean!
    totalCount: Int!
    totalPages: Int!
}

It generated:

public class PageInfo {
  private boolean hasNextPage;
  private boolean hasPreviousPage;
  private int totalCount;
  private int totalPages;

  ..
}

I would like to force the totalCount field to be a Long

Note: I don't want to introduce a Long scalar in the GraphQL schema as from a GraphQL perspective Int is absolutely fine.

Related, I was looking if it was possible to use non-primitives in my generated types so I tried:

typeMapping = ["Boolean": "java.lang.Boolean", "Int": "java.lang.Integer"]

But it does still generates a primitive boolean for non-null schema fields, and only Boolean for non-null fields.
I can see the reasoning behind it but I wonder if I could use Boolean for all fields no matter if it is non-null or not.

[srinivasankavitha]

regarding use of Long, the general recommendation has been to just define Long as a custom scalar in your schema if you need to use it and register it manually as described here: https://netflix.github.io/dgs/scalars/

For the Boolean type, can you elaborate on why you need it if it is a non-nullable?

[paulbakker]

The reason to avoid Long is that JavaScript doesn’t handle it, so you have to be extremely careful with who is consuming your API. There is a Long scalar available in GraphQL-java that you can easily register in DGS, but we don’t register it by default because in general Long is not recommended.

For using boxed types for non-nullable primitives I guess we could introduce a switch in codegen, I would be ok with that.

[marceloverdijk]

Thx for explanation regarding Longs.

For using boxed types for non-nullable primitives I will create an issue. ==> Netflix/dgs-codegen#27

[jillesvangurp]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

Javascript has no 64 bit long because it represents all numbers as a 64 bit double. So, this limits you to 2^53 instead of 2^64. Of course that is still quite a bit more than 2^32 for Kotlin's 32 bit Int. So there's some value in pretending graphql ints are longs on the Kotlin side when dealing with e.g. milliseconds after the epoch. This would require at least 41 bits precision (short term). So, rounding to seconds is a good solution here as that gets you down to 32 bits; which ought to be good enough until we hit the 2038 problem next decade when that stops being enough for accounting for time.

So, custom scalars is probably the most robust solution here. We just gave up and put our iso formatted timestamps in a String. No point in pretending graphql supports either longs or proper dates natively.

[seal-7]

@srinivasankavitha Seems like the Scalars.GraphQLLong is deprecated which we need to build the custom long scalar as per https://netflix.github.io/dgs/scalars/.

Can you help with the correct way of registering the Long Scalar ?

[srinivasankavitha]

If you are using the graphql-java-extended-scalars library, you can wire it up as explained here:
https://netflix.github.io/dgs/scalars/#register-scalar-extensions-via-dgsruntimewiring