DGraph / GraphQL > Wrong types are generated for mutations

Issues GraphQL
, ,
1

The pregenerated mutations do not handle nullables properly for associated types.

Here is an example of a schema:

type Post {
id: ID!
title: String!
content: String!
category: Category! @hasInverse(field: posts)
}

type Category {
id: ID!
name: String!
posts: [Post]
}

After grabbing the generated schema

npx get-graphql-schema https://your-username.us-west-2.aws.cloud.dgraph.io/graphql -j > graphql_schema.json

We observe AddPostInput like so - pay particular attention to CategoryRef

{
"kind": "INPUT_OBJECT",
"name": "AddPostInput",
"description": "",
"fields": [],
"inputFields": [
// ....
{
"name": "category",
"description": "",
"type": {
"kind": "NON_NULL",
"name": null,
"ofType": {
"kind": "INPUT_OBJECT",
"name": "CategoryRef",
"ofType": null
}
},
"defaultValue": null
}
],

CategoryRef is like so

{
"kind": "INPUT_OBJECT",
"name": "CategoryRef",
"description": "",
"fields": [],
"inputFields": [
{
"name": "id",
"description": "",
"type": {
"kind": "SCALAR",
"name": "ID",
"ofType": null
},
"defaultValue": null
},
{
"name": "name",
"description": "",
"type": {
"kind": "SCALAR",
"name": "String",
"ofType": null
},
"defaultValue": null
},
{
"name": "posts",
"description": "",
"type": {
"kind": "LIST",
"name": null,
"ofType": {
"kind": "INPUT_OBJECT",
"name": "PostRef",
"ofType": null
}
},
"defaultValue": null
}
],
"interfaces": [],
"enumValues": [],
"possibleTypes": []
},

Do you see how name is nullable in CategoryRef? It shouldn’t be.

This is an issue, especially when using type safety on the frontend when types generated based on the graphql_schema.json.

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
4

Hi abhimanyusinghgaur, I understand - thank you - I hadn’t consider this scenario indeed. Insightful, thank you :pray:

2 Likes