Comments (6)
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.
Related Issues (20)
- Is the official document of generating codes outdated? or some classes are not auto-generated? HOT 1
- Generated Java-classes naming convention HOT 1
- Generating code from external schemas in JARs - META-INF requirement HOT 6
- Variable declaratino missing wenn miltiple operations are used
- Generate Deprecated Annotation For Queries HOT 1
- Fields with capital letters in the beginning are not deserialised by jackson. java
- Code is not compiling after aliases were added to projections HOT 3
- GraphQL interfaces should still be annotated when using the `@annotate` directive
- How to generate data class with "no arg constructor" and setter? (or a data class with builder) HOT 1
- Polymorphic Interfaces with default implementation HOT 3
- Support Custom Serialization for Date Fields in InputValueSerializer HOT 1
- Error generating classes from generateClientApi or generateClientApiV2 HOT 9
- generating Java types failed with $ in graphql schema comment on interface
- Generating extended types that implement interfaces in the extension fails to generated the actual interface implementation HOT 1
- consider changing generateJava task name HOT 1
- gradle plugin not resolving dependencies properly HOT 1
- use instanceof in generated code
- use jakarta Generated HOT 11
- add appropriate nullity annotations HOT 2
- No way to provide meaningful defaults for scalar type mapping to a specific java type in inputs HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dgs-codegen.