Nullable types for fields with default values in Kotlin

[zappolowski]

Currently a schema like

input ColorFilter {
    color: String = "red"
}

generates a Kotlin class like (shortened to the constructor)

public data class ColorFilter(
  @JsonProperty("color")
  public val color: String? = "red"
)

According to the spec

An input field is required if it has a non‐null type and does not have a default value. Otherwise, the input object field is optional.

To my understanding this would allow to generate

public data class ColorFilter(
  @JsonProperty("color")
  public val color: String = "red"
)

as the field will be always set in this case. This would using the generated class a tad easier as it avoids using ?. or !!.

[kilink]

Your example schema is nullable, the non-nullable version would look like.

input ColorFilter {
    color: String! = "red"
}

See http://spec.graphql.org/June2018/#sec-Type-System.Non-Null

[zappolowski]

Maybe I worded the problem badly, so here's another take.

Using a nullable type with a default value creates a quasi-non-nullable type on the server as in case the field isn't set, the receiver fills in the default value. Using a the schema you suggested kind of defeats the purpose of having a default value as the sender of the query is still required to fill in a value as the type itself is non-nullable and thus the field is considered required.

[kilink]

From the spec you linked to:

An input field is required if it has a non‐null type and does not have a default value.

So technically a non-null type + a default type is not "required" in the sense that a value does not need to be explicitly supplied, is my reading; if the schema is as in your first example, there's still the possibility a client can explicitly pass a null, overriding the default value of "red":

ColorFilter(color = null)

If what you are saying is that in the case of a default, the client simply does not send a value at all for color, and relies on the server to fall back to the default from the schema, then I think that is a separate issue, as the current design of the generated code really doesn't allow for that; with your example, the client would be explicitly sending the default value of "red", instead of omitting it, since the data class is generated with a default argument. I think the serialization code would have to be changed to do what you're suggesting.

I think this boils down to the difference of nullability in the type system, meaning can this field have a null value, vs whether the field is required to be present in the input at all.

[kilink]

I put together some test cases to validate this, maybe it illustrates it a bit better.

For this schema a nullable type for color:

input ColorFilter {
    color: String = "red"
}

type Query {
  things(filter: ColorFilter!): [String!]!
}

Queries such as the following are valid:

query {
  things(filter: {})
}

query {
  things(filter: {color: null})
}

For this schema with a non-nullable type for color:

input ColorFilter {
    color: String! = "red"
}

type Query {
  things(filter: ColorFilter!): [String!]!
}

This query is valid:

query {
  things(filter: {})
}

But this one is not:

query {
  things(filter: {color: null})
}

Now the semantics of sending an explicit null vs. missing property when there is a default, is probably left up to the specific implementation. Anyway, all of this is a long-winded way of saying that I still feel this boils down to:

• a default value in an input allows for the absence of the field in the query.
• whether the field is nullable or not, is a separate concern, and has different implications (is it valid to explicit send null).
• the data class we generate means that the default value is always sent by the client, and the field is never omitted (whether or not that is an issue, I don't know).

[srinivasankavitha]

Thanks @kilink That is a very accurate summary of the design behind the current implementation. Specifically, for code generated classes, the default values of fields are automatically sent as part of the serialized query if the user has not set it. We chose this approach as it is easier to support the majority of use cases compared to adapting the serialization logic, which can get pretty gnarly very quickly.

In most scenarios, it generally doesn’t hurt to send the default value as part of the serialized query. The main use case for not doing so is where you want to explicitly set it to null to test some server logic, and you can still do by setting it explicitly.

On Feb 14, 2021, at 1:01 PM, Patrick Strawderman [email protected] wrote:  I put together some test cases to validate this, maybe it illustrates it a bit better.

For this schema a nullable type for color:

input ColorFilter { color: String = "red" }

type Query { things(filter: ColorFilter!): [String!]! } Queries such as the following are valid:

query { things(filter: {}) } query { things(filter: {color: null}) } For this schema with a non-nullable type for color:

input ColorFilter { color: String! = "red" }

type Query { things(filter: ColorFilter!): [String!]! } This query is valid:

query { things(filter: {}) } But this one is not:

query { things(filter: {color: null}) } Now the semantics of sending an explicit null vs. missing property when there is a default, is probably left up to the specific implementation. Anyway, all of this is a long-winded way of saying that I still feel this boils down to:

a default value in an input allows for the absence of the field in the query. whether the field is nullable or not, is a separate concern, and has different implications (is it valid to explicit send null). the data class we generate means that the default value is always sent by the client, and the field is never omitted (whether or not that is an issue, I don't know). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[zappolowski]

My test case (which I didn't mention before ... sorry for that) was based on using variable substitution in contrast to putting the data directly in the query as you did. It seems like they behave differently.

I've created a repository (based on dgs-examples-kotlin) here to verify. I've used the built-in graphiql endpoint for the tests (if this makes any difference).

Summary: Using the following (simplified) scheme

type Query {
    color(filter: ColorFilter!): String!
}

input ColorFilter {
    color: String = "red"
}

querying color (which just returns the value of the color field of ColorFilter or "Nothing provided" when color is null) using

query ($filter_empty: ColorFilter!, $filter_explicit_null: ColorFilter!) {
  variable_empty: color(filter: $filter_empty)
  variable_explicit_null: color(filter: $filter_explicit_null)
  inline_empty: color(filter: {})
  inline_explicit_null: color(filter: {color: null})
}

with variables being

{
  "filter_empty": {},
  "filter_explicit_null": {
    "color": null
  }
}

it yields

{
  "data": {
    "variable_empty": "red",
    "variable_explicit_null": "red",
    "inline_empty": "red",
    "inline_explicit_null": "Nothing provided"
  }
}

As you can see variable_explicit_null and inline_explicit_null yield different returns. To my understanding this is caused by applying different rules on de-serialization (and I don't know, which one is correct).