The generated query for a type in GraphQL currently looks like this:
queryType(...):[Type]
I’m using some codegen tools to get strict typing on calls to my GraphQL endpoint, which has made me think of this question: when would the return type of a query be null (instead of an empty array) and when could the elements inside the array be null?
Ping @graphql
Just realised I might need to clarify a bit… I guess I’m asking why the type is not:
queryType(...):[Type!]!
Let’s take an example schema,
type User {
id: ID!
name: String!
hobbies: [Hobby] @hasInverse(field: user)
}
type Hobby {
id: ID!
name: String!
user: User! @hasInverse(field: hobbies)
}
GraphQL will generate below queries for us
We see three types of queries
Normal queries: They are of the type query+typename(queryUser,queryHobby) and returns list of objects.
If there is no object in the response or you don’t have permission to see them it returns an empty array.
getQuery: They take ID or @id as argument and returns a single object if present and you have permission to access themotherwise returns null.For example, getHobby and getUser queries.
Aggregate queries: These are used for aggregation results like getting count,min,max. They will always return the field queried , null or 0 if there is no 0object present.
Thanks for the reply. If an array will always be returned, even if no results or auth error the response type should be [Type]!. Otherwise I have to make sure there is an array there (not null) before I can work with the response.
And unless items in the array can be null (doesn’t seem likely based on my understanding of dgraph) then the response type should actually be [Type!]!. Otherwise I need to check each item is not null before accessing fields on it.
Sounds like it should be a simple fix… unless I’m missing some cases where the above is not true? @michaelcompton ?
I think this goes along the lines of my clarification for my own purpose of the !:
But I did not take an account for null
It appears my logic may be off
and another reply:
They can all be empty arrays, but [ID] can contain elements that are null whereas [ID!] can’t.
@amaster507 I think your understanding is close, but [ID!] is not about emptiness of the array but the nullability of the elements of that array. Same for fields, actually…
type Foo { bar: String! }
Means you can expect a Foo to always have a String value for bar.
type Foo { bar: String }
Means it might be a String, or null
I will make mental note and update that linked topic as my understanding is wrong so there is actually not an issue. I guess GraphQL has no syntax to ensure that an array is not empty?
Not that I’m aware of.
There is one more type of query checkTypePassword(name: String!, pwd: String!): Type, that can return null.
This case won’t occur , if there is no response in a list then we don’t return null but empty list [].
We can have this case [null] if there is some in the marshaling of the response. You should check for the null value before accessing every item from the response.
We haven’t added constraints on the query response like [Type]! or [Type!]! to keep API flexible even though the first case is unlikely to occur. For example if we now enforce these conditions and in future we allow null response instead of [] , then that will be breaking change.
So, I suggest you to check for null value before accessing a list or items in a list of the response.
Could you explain the marshalling case? Would be useful to understand so I can code for it 
I’d humbly request you to at least consider [Type]! though – null pointer exceptions are a billion dollar industry, so I’m always for avoiding null where we can. In this case we are asking dgraph for a list of records for a specific type.
If the Type exists (which it has to), there is either no records [], or some [...]. I can’t see how returning null from that kind of query might be useful in the future.
Thanks for your consideration
ok, sure. I will discuss it with the team and let you know.
