Implement (simple) type casts on InputArguments for ID and more

[EugenMayer]

Mainly motivated due to the fact that with 4.6.0 the ID is enforced to be a string, see ( #578 ), it seems to be a fairly repeated task to cast the id into an Long / Integer over an over again.

I would love to have a simple typecast tooling dealing with those simple conversions - it keeps it semantically tight to the declaration, does not get overseen in the code (and does also not need an additional variable in the method over and over again like attachmentIdLong or whatever people tend too.

There are voices to extend the cast to more cases, I personally think that we should keep it simple. If there are complicated typecast, they will be rare and most probably need complex logic/handling anyway, so are going to need a proper tool method.

Use cases

• ID conversion (string to something numeric)
• Date conversion? (seems to complicated, I would not do that)
• String to Enum (might be durable)
• Ordinal to Enum (durable)

Ideas

@InputArgument(cast = "java.lang.Long") String attachmentId

or just something like

@InputArgument(castTo=DgsCast.toLong) String attachmentId

@InputArgument(toInt=DgsCast.toInt) String attachmentId

Where DgsCast is an Enum - the latter would limit the implementation to specific types so it does not get out of hand. Simple conversions - that's it, not a magic full-fledged DGS type caster.

[paulbakker]

It would have to account for the same casts in objects as well. E.g. what if you have:

type Query {
  movies(filter: MovieFilter): [Movie]
}

input MovieFilter {
  movieId: ID
}

The type for the @InputArgument is MovieFilter, but now the MovieFilter would have to convert the movieId field.

I think this might be a can of worms that causes more issues and confusion than it solves.
Would like to hear input from others though.

[asusnjar-nuvalence]

Many things in JSON are serialized as Strings but that does not make them strings: phone numbers, SSNs, timestamps, URLs, etc. Sure, EVERYTHING can be represented as a string (or a number). It isn't about representation or serialization but the meaning. ID is not a string. It is an indivisible piece of data that identifies something else, not meant to be processed otherwise (i.e. no arithmetic, no parsing, no substrings) - it tells the clients to not mess with it, to not display it as it carries no data beyond identification.

On the input side, IDs can be specified either numerically (123) or as strings ("123") - both will be accepted. Tested with graphql-java and GraphiQL. In that sense, GraphQL ID should accept many Java types including Long and UUID, for example, to name two common examples.

Then there is the pragmatic nature of this - applications may presently use Longs and need to communicate them internally as such but may wish to switch to UUIDs later (one example), when they get to it. Exposing them as IDs sets the contract right but DGS seems to be in the way here presently.