String cast issue: field name is a graphql type and a reserved words in many languages

[jperezr21]

Version Information

Server Version: 2.8.0
CLI Version (for CLI related issue): 2.8.0

Environment

OSS

What is the expected behaviour?

Fields in the graphql schema don't clash with graphql types and common reserved words in many languages.

Keywords

cast, String, jsonb

What is the current behaviour?

Schema contains fields named String. E.g.:

input jsonb_cast_exp {
  String: String_comparison_exp
}

How to reproduce the issue?

1. Export schema that uses jsonb, or any of the postgres types in Add _cast support for other postgres datatypes fix #6050 and fix #5426 #8524

Screenshots or Screencast

Error in autogenerated dart code for flutter app:

Please provide any traces or logs that could help here.

Issue exists with JSONB since 2.5.0, but recently it was added to other types in this PR: #8524

Any possible solutions?

Use string or _String.

Can you identify the location in the source code where the problem exists?

Not sure.

If the bug is confirmed, would you be willing to submit a PR?

If someone can point me to the code, yes.

[BenoitRanque]

String is a valid GraphQL name, so this is more an issue with the generated code, than an issue with hasura itself.

As such, removing the bug label and adding the enhancement label.

This issue may also be resolvable with your codegen tool of choice.
While I am unfamiliar with dart, most languages allow use of reserved words as keys in JSON objects, if correctly escaped.

Edit: Please note I am not closing this issue, as this is valid feedback.

If you are another user affected by this problem, please leave feedback here so we can better gauge the impact of this particular change.

[zellidev0]

I have the same problem.
Using the graphql_codegen package can't generate code due to the same error as mentioned in the question.

The name String in the following snipped makes the code generator use String as an indentifier of a getter in dart.

input jsonb_cast_exp {
  String: String_comparison_exp
}

Currently the proposed fix (using _String) works fine, but it would be great to have that fixed.