MethodDataFetcher should allow ObjectMapper.convert() for buildArg

[shevek]

The implementation of buildArg() isn't very strong, and is somewhat brittle if e.g. a constructor parameter doesn't match an item in the GraphQL schema. We should be permitted to just use Jackson's ObjectMapper.convert() to build the arguments somehow, instead of using buildArg().

[FLXT-Qi]

Strongly agree

[freelancer1845]

Maybe another way would be:

Instead of looking for a constructor that exactly matches the schema use a NoArgsConstructor and then populate the fields (or only do this as fallback).

My use case:

public interface Pattern {
    @GraphQLID
    @GraphQLField
    @GraphQLNonNull
    public String getName();
}

@Setter
@Getter
public abstract class PatternBaseType implements Pattern  {

    @GraphQLID
    @GraphQLField
    @GraphQLNonNull
    public String name;
}


@Data
public class SpecialPattern extends PatternBaseType implements Pattern {
    @GraphQLField
    public Double width;
}

public class Mutations {
    @GraphQLField
    @GraphQLNonNull
    public static SpecialPattern createSpecialPattern(SpecialPattern blueprint) {
        return ...
    }
}

Now SpecialPattern needs a Constructor that takes in the name and the width as parameter otherwise the object is not constructed correctly.

So I guess my question is why does buildArg only consider the constructor and not the JavaObjects fields?

[Fgerthoffert]

Hi @shevek , @FLXT-Qi , @freelancer1845

We're helping with project maintenance and reviewing the list of opened PRs and Issues.

This issue was created quite a while ago, we were wondering if you were still interested in the outcome, please let us know if this is the case.

Without an answer by October 1st, 2023, this issue will be closed as "inactive" (and can always be re-opened later on if needed).

Thanks,