Support for partial mutations (PATCH Semantic)

[jmbarroso]

Hi,

I was wondering if the DGS framework has any pattern to implement partial mutations (HTTP PATCH-like). I didn't find anything on the documentation, but I wanted to check if it has been solved already.

I can see how using the input type as Maps in the data-fetcher could help, but I wondered if there is a pattern that involves using the Kotlin Generated Types.

Thank you!

[paulbakker]

Are partial mutations something in the GraphQL spec? I’m not aware of this being supported.

I don’t think there’s anything specified about how a server is supposed to handle a mutation. If, for example, you have a mutation that takes an @InputArgument of a (generated) class, and not all fields are set, it’s up to the code in your datafetcher to handle that correctly. “Handling correctly” would depend a lot on how you store your data, so I’m not sure there’s anything useful the DGS framework can do.

[jmbarroso]

I believe it is mentioned in the Input Coercion section. That said, there are usually discussions about this in the community.

If no value is provided for a defined input object field and that field definition provides a default value, the default value should be used. If no default value is provided and the input object field’s type is non‐null, an error should be thrown. Otherwise, if the field is not required, then no entry is added to the coerced unordered map.

If the value null was provided for an input object field, and the field’s type is not a non‐null type, an entry in the coerced unordered map is given the value null. In other words, there is a semantic difference between the explicitly provided value null versus having not provided a value.

The idea here is to be able to know when a field was set to null and when a field is not present as input. Does it make sense?

About how DGS could help, I think that generated input types could help if they have an interface to check if a nullable field was set or not. Something on the line of input.myField and input.isMyFieldPresent will help the backend to get semantics and do the right update.

[jmbarroso]

Hi all,

Did you have the chance to look into my answer? Any thoughts @paulbakker?

Thank you!!

[victorlevasseur]

In our API, we use an intermediate input object : if the whole object is null, it means we don't want to patch the field, if the value inside the object is null, it means we want to set the field to null.

Unfortunately, we have to create such intermediate objects for each types of input data but it works well

[jmbarroso]

Thanks for your reply @victorlevasseur.

Do you mind sharing a bit more about your strategy? are you copying from the input generated by DGS to an intermediate object? or you won't use the "input classes" generated by the framework? (not sure if you can share an example, that would be great!)

[victorlevasseur]

We don't have our GraphQL API directly connected to databases. But we communicate with gRPC services and we map the DGS generated object to what our gRPC API needs to do the patch (we even decide which call to do or not depending on which fields the client wants to patch). But nothing fancy, we still have a lot of boilerplate code unfortunately.

[jmbarroso]

Got it. I’m trying to do something similar.

I guess that what I’m trying to understand is with the current implementation when you receive a mutation input, how do you determine what fields were passed by the GraphQL client. How do you identify a null intended to set the value to null versus no present?
Are you using your input types instead of using DGS auto-generated classes?

Thanks, @victorlevasseur !!!

[jmbarroso]

@victorlevasseur, @paulbakker, any chance you can chime in my previous question?.

It is some guidance about how are you identifying a null intended to set the value to null versus no present? (I was expecting some code in the generated input to ask when a field was present or not).

Thanks a lot!!

[jmbarroso]

FYI, Found an answer related to this: #796