DGraph / GraphQL > Wrong types are generated for mutations

Issues GraphQL
, ,
2

It is the current design of the schema that is generated when you supply the types.

So, when you give a type, three different kinds of inputs are generated for it:

  • AddTypeInput (AddPostInput, AddCategoryInput, …)
  • TypePatch (PostPatch, CategoryPatch, …)
  • TypeRef (PostRef, CategoryRef, …)

Only the AddTypeInput kind of inputs honor non-null behavior, the other two kinds of inputs don’t. The reason being, when you are going to use addType mutation, you will always be adding the type using the AddTypeInput kind of inputs, where you can’t supply null values for non-null fields.

So, if you were using addPost, then you can’t supply any of the fields from Post as null values, as all of them are non-null. But, since Category is a field inside Post, and while adding Post you may want to refer to an already existing category in your DB using its ID, or you may want to create a completely new category altogether. For such cases, TypeRef kind of inputs are used. They can refer to an existing node of that type or they can represent a completely new value for that type as well. And, to do both of these things at the same time, they can’t respect non-null behavior. So, nullability checks aren’t enforced on fields of TypeRef kind inputs.

Consider this scenario:

mutation {
  addPost(input: [{title: "Post1", content: "my post", category: {id: "0x21"}}]) {
    post {
      title
      category {
        name
      }
    }
  }
}

If the Category.name field is marked non-null inside CategoryRef, then you won’t be able to do something like above.

On the other hand, if you were adding a category using addCategory mutation, you won’t be able to supply null values for the non-nullable fields in category, because AddCategoryInput honors null check.

5 Likes