Customize request serialization when using @InputArgument

[alexp1234]

***EDIT: It looks like this is happening here:

dgs-framework/graphql-dgs/src/main/kotlin/com/netflix/graphql/dgs/internal/DefaultInputObjectMapper.kt

Line 196 in 479455d

val mappedList = input.filterNotNull().map { listItem ->

So even if the graphql type explicitly allows null values in an array they're always going to be filtered out?

Hi Team,

Is there a way to control the serialization of input arguments when using @InputArgument("myInput")? I'm noticing that when the input property contains null values in a String array, they're being filtered out which is not what I want. I see the null value in the array when using the DgsDataFetchingEnvironment approach, so I think it's getting filtered out on serialization.

For example [null] becomes [],
["myItem", null] => ["myItem"]

Any help would be greatly appreciated!

[srinivasankavitha]

Which release of the DGS framework are you using? For a simple test schema like this: ``` testStrings(names: [String]) : String ``` I do see null being one of the values when parsed out using a data fetcher like this: ``` @DgsQuery public String ***@***.*** List<String> names) { List<String> inputs = names; return "hello "; } ``` `inputs` contains both null and non-null values. Is this your use case?

…

On Mon, Mar 13, 2023 at 8:00 AM Alex Pickrell ***@***.***> wrote: Hi Team, Is there a way to control the serialization of input arguments when using @InputArgument("myInput")? I'm noticing that when the input property contains null values in a String array, they're being filtered out which is not what I want. I see the null value in the array when using the DgsDataFetchingEnvironment approach, so I think it's getting filtered out on serialization. For example [null] becomes [], ["myItem", null] => ["myItem"] Any help would be greatly appreciated! — Reply to this email directly, view it on GitHub <#1453>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXPKUHFFZ7JJ6QKC5MLW34ZBBANCNFSM6AAAAAAVZGG744> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[alexp1234]

Hello and thanks for the reply!

The version I am using is 4.9.20, the following is a simplified version of the graphql schema

"""
input myInputType {
myListType: [String]
}

"""

If I make the following request to my endpoint using each of the two ways below, the behavior is different:
myListType: [null]

Scenario 1: Using @InputParameter syntax:

@DgsQuery
public MyReturnType getData(@InputParameter("input") final MyInputType myInputType) {
     int len = myInputType.myListType.length; // Length = 0, []
}

Scenario 2: Using DgsDataFetchingEnvironment syntax

@DgsQuery
public MyReturnType getData(final DgsDataFetchingEnvironment dfe) {
      final LinkedHashMap<String, String> map = dfe.getArgument("input");
      MyInputType myInput = OBJECT_MAPPER.convertValue(map, MyInputType.class); // simple jackson mapper implementation to convert to my type from map
      int len = myInput.myListType.length; // Length 1, [null]
      
}

This makes me think that null values are being filtered out of collections in the DGS input mapper

[srinivasankavitha]

I see, right. We do filter null values in the DefaultInputObjectMapper implementation. However, you can provide your own custom input object mapper by providing a InputObjectMapper bean that implements these methods as well: https://github.com/Netflix/dgs-framework/blob/master/graphql-dgs/src/main/kotlin/com/netflix/graphql/dgs/internal/InputObjectMapper.kt Our default implementation is here: https://github.com/Netflix/dgs-framework/blob/master/graphql-dgs/src/main/kotlin/com/netflix/graphql/dgs/internal/DefaultInputObjectMapper.kt This will allow you to change the behavior for your use case. Hope this helps.

…

On Tue, Mar 14, 2023 at 8:11 AM Alex Pickrell ***@***.***> wrote: Hello and thanks for the reply! The version I am using is 4.9.20, the following is a simplified version of the graphql schema """ input myInputType { myListType: [String] } """ If I make the following request to my endpoint using each of the two ways below, the behavior is different: myListType: [null] Scenario 1: Using @InputParameter syntax: @DgsQuery public MyReturnType ***@***.***("input") final MyInputType myInputType) { int len = myInputType.myListType.length; // Length = 0, [] } Scenario 2: Using DgsDataFetchingEnvironment syntax @DgsQuery public MyReturnType getData(final DgsDataFetchingEnvironment dfe) { final LinkedHashMap<String, String> map = dfe.getArgument("input"); MyInputType myInput = OBJECT_MAPPER.convertValue(map, MyInputType.class); // simple jackson mapper implementation to convert to my type from map int len = myInput.myListType.length; // Length 1, [null] } This makes me think that null values are being filtered out of collections in the DGS input mapper — Reply to this email directly, view it on GitHub <#1453 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXPLGCS46YKTDKFWRYDW4CDB7ANCNFSM6AAAAAAVZGG744> . You are receiving this because you commented.Message ID: ***@***.***>

[alexp1234]

Okay great thank you for this information. I'm not expecting a change to be made but do you mind if I ask what the rationale is for filtering out null values out of collections considering that it is acceptable to have nullable types inside of collections in GraphQL types?

IMO if end users don't want null inside of their collections they should specify the graphql type as non-nullable instead of relying on DGS to filter for them.

[srinivasankavitha]

Thanks for the feedback. The nullability applies to the field itself, so in this case the list itself cannot be specified as null, and not for values inside the list. Could you describe the use case that would need to preserve null values inside a list?

…

On Thu, Mar 16, 2023 at 6:22 AM Alex Pickrell ***@***.***> wrote: Okay great thank you for this information. I'm not expecting a change to be made but do you mind if I ask what the rationale is for filtering out null values out of collections considering that it is acceptable to have nullable types inside of collections in GraphQL types? IMO if end users don't want null inside of their collections they shoul specify the graphql type as non-nullable instead of relying on DGS to filter for them. — Reply to this email directly, view it on GitHub <#1453 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXJ6S3ILWUOCSYKGEFDW4MHYVANCNFSM6AAAAAAVZGG744> . You are receiving this because you commented.Message ID: ***@***.***>

[alexp1234]

Sure I definitely can!

Let's say that I want search for users who have a Firstname of 'Alex' OR who have not yet had a first name assigned in our DB (null) through a graphql endpoint

I would send an input array as part of the request like this: firstNames: ['Alex', null] that corresponds to a graphQL property:
FirstNames: [String]!

Which would get translated by the server in query language to something like 'Where Firstname in ('Alex', null)' depending on the DB query language.

In this scenario null is a valid value and intentionally allowed so that I can search the datastore for the records/documents with that value.

If I didn't want to allow the ability to search for records/documents with null firstNames, I would specify the GraphQL type as

FirstNames: [String!]!

Instead of

FirstNames: [String]!

[srinivasankavitha]

Right, ok. My apologies for missing that. I think the implementation currently does that to maintain the behavior we had early on (post refactoring). That said, it should be easy enough to change this without breaking existing backwards compatibility assuming there implementations are not relying on this filtering. Will look into fixing this in a future release. Thanks for bringing this up.

…

On Thu, Mar 16, 2023 at 10:02 AM Alex Pickrell ***@***.***> wrote: Sure I definitely can! Let's say that I want search for users who have a Firstname of 'Alex' OR who have not yet had a first name assigned in our DB (null) through a graphql endpoint I would send an input array as part of the request like this: firstNames: ['Alex', null] that corresponds to a graphQL property: FirstNames: [String]! Which would get translated by the server in query language to something like 'Where Firstname in ('Alex', null)' depending on the DB query language. In this scenario null is a valid value and intentionally allowed so that I can search the datastore for the records/documents with that value. If I didn't want to allow the ability to search for records/documents with null firstNames, I would specify the GraphQL type as FirstNames: [String!]! Instead of FirstNames: [String]! — Reply to this email directly, view it on GitHub <#1453 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXPUZO27SXM5I7FYDLTW4NBUBANCNFSM6AAAAAAVZGG744> . You are receiving this because you commented.Message ID: ***@***.***>

[alexp1234]

No worries at all! And that's perfectly fine, we have a workaround in place that is simple enough, just thought that I would bring it up and see.

Thanks!