GraphQL error: Non-nullable field was not present in result from Dgraph

I agree with this.

But, disagree with this as one would lose the ability to have non-null fields at all in a query response.
and also because below quote is more true:

So, I think, we should propose this:

Let the ! on fields represent that a field in the query response is non-null. Instead, provide the capability to the user to toggle the fields inside mutation inputs as non-null. This can also allow us to explicitly specify nullability for each kind of mutation input (add, update-set, update-remove). In addition, we can also allow users to be able to choose which fields they want in the addInput vs which ones they want in the updateInput, etc. This can be achieved with a new directive like this:

directive @input(
  add: InputParams,
  update: UpdateInputParams
) on FIELD_DEFINITION

input InputParams {
  # defaults to false
  skip: Boolean,
  # defaults to
  # for add inputs: whether `!` has been defined on the field in schema
  # for patch inputs: false
  nonNull: Boolean
}

input UpdateInputParams {
  set: InputParams
  remove: InputParams
}

So, now I would be able to define a schema like this:

type Note @auth(
  query: { rule: "query { queryNote(filter: {isPublic: true}){ id } }" }
  # ...
) {
  id:ID!
  text: String!
  isPublic: boolean
  by: Author @input(add: {nonNull: true}, update: {set: {skip: true}, remove: {skip: true}})
  version: String @input(update: {set: {nonNull: true}, remove: {skip: true}})
}

which would generate following inputs:

input AddNoteInput {
  text: String!
  isPublic: Boolean
  by: Author!
  version: String
}
input SetNotePatch {
  text: String
  isPublic: Boolean
  version: String!
}
input RemoveNotePatch {
  text: String
  isPublic: Boolean
}

This allows me to say things like:

  1. A Note’s text can’t be null in the query response.
  2. A Note’s author can be null in the query response.
  3. A Note’s author must be provided while adding the Note, but after that, you can’t update or remove the author from the note.
  4. A Note’s version may not be provided while adding the note, but after that, every time you update a note, you must update its version. In addition, you can’t remove a note’s version.

Later, we may extend @input to also support default values as well like this:

type Note {
  ...
  version: String @input(add:{default: "v0"}, update: {set: {nonNull: true}, remove: {skip: true}})
}

which allows me to say that if I don’t provide a version while adding a Note, it should default to “v0”.

2 Likes