You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we are trying to use GraphQL node query pattern with DGS to obtain a partial response for nodes query.
Let's use this schema:
type Query {
"Get node by id"
node(id: ID!): Node
"Get nodes by ids"
nodes(ids: [ID!]!): [Node]
}
interface Node{
id: ID!
}
type Car implements Node {
id: ID!
color: String!
year: Int!
}
So we have a node interface and some actual graphql objects that implement this interface. For example Car in our case.
Node query is not a problem. It returns data or error
The nodes query doesn't work as expected because it also returns data or error but we want partial response meaning data & error
Assume, that in our Database we have the following cars: ["Mazda", "Toyota", "Opel"] we do not have BMW.
When we run the query:
query demoCar{
nodes(ids: ["Mazda", "Toyota", "BMW"]) {
... on Car {
__typename
id
color
year
}
}
}
We used standard DGS Annotations for getting the nodes.
@DgsQuery
fun nodes(@InputArgument ids: List<String>): List<Node> {
//Some logic to obtain a proper service and then the data
return CarService.getNodesData(ids)
}
When there is an exception during the execution of CarService.getNodesData(ids) then the whole response is data = null & errors contains details.
From my point of view, it makes sense, because in this case, nodes behave like field... and when the exception is thrown, it always contains data or null (the error block is filled with information).
Main Question
So how we can achieve a partial response in this case? We known, that DB returns only 2 Cars but query requested 3 cars. We want to return at least what we found, together with error detail.
Expected Behavior
When the exception is thrown during the nodes query, the exception handler is triggered, and processed, and the whole process continues until everything is processed and then the partial response is returned.
Basically same problem was asked here but also without resolution.
I found a resolution by using DataFetcherResult but it is not exactly what we are looking for, because in that case, everything has to be in try/catch and error part has to be constructed manually, and that isn't what we are looking for.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi Everyone,
we are trying to use GraphQL node query pattern with DGS to obtain a partial response for nodes query.
Let's use this schema:
So we have a node interface and some actual graphql objects that implement this interface. For example Car in our case.
Node query is not a problem. It returns
data or error
The nodes query doesn't work as expected because it also returns
data or error
but we want partial response meaningdata & error
Assume, that in our Database we have the following cars: ["Mazda", "Toyota", "Opel"] we do not have BMW.
When we run the query:
Current Result
We used standard DGS Annotations for getting the nodes.
When there is an exception during the execution of
CarService.getNodesData(ids)
then the whole response is data = null & errors contains details.From my point of view, it makes sense, because in this case, nodes behave like field... and when the exception is thrown, it always contains data or null (the error block is filled with information).
Main Question
So how we can achieve a partial response in this case? We known, that DB returns only 2 Cars but query requested 3 cars. We want to return at least what we found, together with error detail.
Expected Behavior
When the exception is thrown during the
nodes query
, the exception handler is triggered, and processed, and the whole process continues until everything is processed and then the partial response is returned.Basically same problem was asked here but also without resolution.
I found a resolution by using
DataFetcherResult
but it is not exactly what we are looking for, because in that case, everything has to be in try/catch and error part has to be constructed manually, and that isn't what we are looking for.Beta Was this translation helpful? Give feedback.
All reactions