Mapping fields for Input Types with different names between schema and Java Object

[gaganis]

Is there a way to map fields for input types? I have been unable to find how to do this neither in the documentation or by searching the web.

For example to be able to map full_name in the schema to fullName in the java object:

input CreateUserInput {
    full_name: String
}

to

public class CreateUserInput {
    private String fullName;  // Must match GraphQL schema

    public String getFullName() {
        return fullName;
    }

    public void setFullName(String fullName) {
        this.fullName = fullName;
    }
}

We are migrating our app from https://github.com/graphql-java-kickstart and we used to do that using jackson@JsonProperty.

Any pointers would be greatly appreciated

Thanks
Giorgos

[rstoyanchev]

We used to decode through Jackson, but it involves serializing the argument map to JSON first, which can cause issues with scalar value formatting, see #122. We now use our own mechanism, the GraphQlArgumentBinder. Currently, it does not support this kind of mapping. We could consider some sort of naming strategy, or a Function to map keys from the argument map.

[gaganis]

Thanks for you reply

In my POV something like this would make a lot of sense to me. Not sure if this would fit any of your suggestions @rstoyanchev

public class CreateUserInput {

    @ShemaMapping(field="full_name")
    private String fullName;  // Must match GraphQL schema
    ...
}

[rstoyanchev]

@SchemaMapping is associated with mapping schema type fields through controller methods, and as such it is not something we would reuse for input type fields. Naming aside, I understand what you're suggesting. I think it makes sense to build some flexibility into argument binding to allow differences while letting you pick the most suitable approach.

For naming convention differences like the one that's described here (underscore to camelback), it would be better to configure a general mapping function once centrally vs having explicit mappings in many places.

We'll add something on GraphQlArgumentBinder to make it configurable with a callback that lets you customize the argument name. The callback would also provide target type information (with access to annotations), so it should be flexible enough for any approach.

[JBodkin-Amphora]

We'll add something on GraphQlArgumentBinder to make it configurable with a callback that lets you customize the argument name. The callback would also provide target type information (with access to annotations), so it should be flexible enough for any approach.

I'm interested in being able to configure the target type information, when mapping an object or an collection element depending on the attributes on the input payload. Jackson has a similar concept - @JsonTypeInfo(use = JsonTypeInfo.Id.DEDUCTION)

For example:

input UpdateCountryInput {
  aliases: [CountryAliasInput]
}

input CountryAliasInput {
  id: ID
  language: String
  alias: String
}

If the id is present in the payload, I would like to map to UpdateCountryAliasInput which will optionally run the validation, based on whether those fields are present in the payload. If the id is absent in the payload, I would like to map to CreateCountryAliasInput which will always run the validation.

record UpdateCountryInput(ArgumentValue<List<CountryAliasInput>> aliases) {}

interface CountryAliasInput {}

record CreateCountryAliasInput(@NotNull String language, @NotNull String alias) implements CountryAliasInput {}

record UpdateCountryAliasInput(@NotNull String id, @NotNull ArgumentValue<String> language, @NotNull ArgumentValue<String>) implements CountryAliasInput {}

To make things more challenging for me, sometimes the id isn't automatically generated and instead defined by the user. In these instances, I would also want to access the nth parent level in payload or mutation arguments as I would need to run a query to check if the entity exists or not. I'm dealing with a legacy system at the moment, that requires these to be a single mutation rather than multiple mutations.

TLDR: I'm trying to match the Kubernetes merging on manifests files