Nullable types for fields with default values in Kotlin about dgs-codegen HOT 6 OPEN

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

from dgs-codegen.

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.

from dgs-codegen.

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.

from dgs-codegen.

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).

from dgs-codegen.

from dgs-codegen.

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).

from dgs-codegen.