Is it expected that object property names cannot be mapped in the client response using @Name annotation?

[alexpoletaev]

I'm not sure if it's feature or bug, but I haven't find a way how to map object properties with different names from the client response using native smallrye graphql @Name annotation.
For example, I'm getting next response:

{
    "integer": null,
    "float": 7.0,
    "string": null
}

since those property names are reserved in Java, I cannot use same names for the properties. I though it's possible to use a @Name annotation like this:

public class SomeClass {

    @Name("float")
    private Float floatValue;

    @Name("integer")
    private Integer integerValue;

    @Name("string")
    private String stringValue;
}

however here you will find that it takes an alias for name and according to this method it seems that it should be possible to use @Name annotation, but here you will find that if the @Name annotation is used, then the raw name is returned. The workaround is to use the Jackson's @JsonProperty annotation, but I think it should be possible to do the same with the @Name annotation as well

[phillip-kruger]

Yes you should be able to use @Name and this seems to be a bug. cc @jmartisk

[jmartisk]

I can't reproduce this problem (... or what do you actually get as the behavior?).
I tried adding these fields

@Name("float")
Float floatValue;

@Name("integer")
Integer integerValue;

@Name("string")
String stringValue;

Then in the generated query, it asks for (...) floatValue:float integerValue:integer stringValue:string (...), so it expects the server to have fields named string, integer, float, and it renames them to the target names (this is the "raw" name of the field that you are referring to), which is just an internal trick to make deserialization easier. The values are then properly deserialized in the response object.

So if it doesn't work correctly for some cases, I think I need a reproducer.

To see the generated query, add this to the configuration:

quarkus.log.min-level=TRACE
quarkus.log.category.\"io.smallrye\".level=TRACE

[alexpoletaev]

@jmartisk , @phillip-kruger, here is the reproducer (see tests)
quarkus-graphql-client-issue.zip

[mskacelik]

Hello @alexpoletaev
It is a bit confusing, but the @Name annotation renames the field, and the previous name of the field is the alias. This alias name needs to be referenced in the GraphQL response from the server side. So your response from the server (from your test case) should be:

{
    "integerValue": null,
    "floatValue": 7.0
}

Please see a test:

smallrye-graphql/client/tck/src/main/java/tck/graphql/typesafe/AnnotationBehavior.java

Line 85 in 266bc1e

void shouldQueryObjectWithRenamedFields() {

[alexpoletaev]

@mskacelik thank you for the answer, but there is no way I can change the response from the 3rd party API in real project. The real response almost the same as I posted here earlier and I need a way to map those properties into the java class. And you are saying that there is no way to map class properties in the graphql client response with the builtin annotations from the graphql module and I need a 3rd party library (jackson) for that, am I right? Honestly, that sounds strange. Or do I miss something?

UPD: From the test I see that it's possible to workaround that with the graphql aliases, but I want to understand if it's possible to do within Java code without 3rd party libraries. Thanks in advance.

[t1]

Well, you can use the @Name annotation to use a GraphQL field name (e.g. foo) different from your Java field name (e.g. bar). This works straight forward by using the GraphQL Alias mechanism. This renders a request containing bar:foo, i.e. the service knows that you want the field foo, but it returns it in the JSON response with the name bar... which we then can easily and directly map to your field of that name. No need for Jackson or anything.

Only when you need more substantial mappings, you'll have to write an intermediate class to load the GraphQL response, and then do your mapping magic manually.