graphql-spqr
graphql-spqr copied to clipboard
Wrong name of input fields in queries
I have this kind of API:
query {
api {
person(id: "2") {
id
name
}
}
}
defined in that way:
public class ApiRoot {
@GraphQLQuery
public ApiType api() {
return new ApiType();
}
}
@GraphQLType
public class ApiType {
@GraphQLQuery
public Person getPerson(@GraphQLInputField(name = "id") String id) {
return new Person();
}
}
If I check documentation in GraphiQL I see:
person(arg0: String): Person
but I expected:
person(id: String): Person
A part of Introspection query:
{
"name": "person",
"args": [
{
"name": "arg0",
"description": "",
"type": {
"kind": "SCALAR",
"name": "String"
}
}
],
The same issue is for top-level queries.
Java does not keep parameter names unless you tell it to.
If you want to skip adding @GraphQLArgument, compile with the -parameters option or the names will be lost. If you're using Maven to build, you can configure it the same way SPQR itself does.
Didn't this trigger a lot of warnings in the log?
Ok, now I see the error in logs:
https://github.com/leangen/graphql-spqr/wiki/Errors#missing-argument-name
but the link is broken (there is no missing-argument-name paragraph).
But if I specify the name in the annotation: @GraphQLInputField(name = "id") the -parameters flag has nothing to do here. (The name specified in an annotation should be in GraphQL Schema IMO).
Wrong annotation. It's @GraphQLArgument you're looking for.
@GraphQLInputField is for mapping fields on input objects. While in their current incarnation, the same annotation could have been used for both, having them separate promises easier API evolution.
And true, if you give the explicit name the -parameters option is not needed.
Ok, thanks for the explanation it works. But still the link: https://github.com/leangen/graphql-spqr/wiki/Errors#missing-argument-name is broken.
Wrong annotation. It's
@GraphQLArgumentyou're looking for.@GraphQLInputFieldis for mapping fields on input objects. While in their current incarnation, the same annotation could have been used for both, having them separate promises easier API evolution. And true, if you give the explicit name the-parametersoption is not needed.
Thanks for this @kaqqao ! For anyone trying to do this for kotlin you can add this using:
// build.gradle.kts
tasks.withType<KotlinCompile> {
kotlinOptions {
javaParameters = true
}
}
Not sure what the groovy equivalent would be. See SO answer