Open CalvinQuark opened 11 months ago
I'm quite new to working with GraphQL. Consequently, I didn't yet realize when I submitted this issue that one could alternatively craft this query as:
{
series(filter: {id: {eq: 10001}} ) {
items {
id
name
books(filter: {title: {contains: "m"}}) {
items {
id
title
year
pages
}
}
}
}
}
This query version filters the response correctly as intended. Nevertheless, the behavior still seems incorrect when the inner filter is instead shifted to the outer entity as explained in the issue submission.
Thanks for reporting. We have this on our radar but don't have a timeline that we can share.
What happened?
Whereas the fix for Issue 825 correctly addresses hierarchical/relationship filtering when the outer entity is on the many side of a one-to-many relationship, the inverse filtering behavior where the outer entity is on the one side of a one-to-many relationship seems incorrect.
The following GraphQL query pertaining to the T-SQL schema, data, and dab-config.json provided in Issue 825 has the outer entity, books, as the many side and the inner entity, series, as the one side of the relationship.
Which yields:
The foregoing query fetches a properly filtered response based on the conjunction of the two filter predicates.
However, if one inverts the query, with the outer entity, series, the one side of the relationship and the inner entity, books, the many side of the relationship:
The result is:
This filtering behavior seems incorrect. The query returns all items in the books collection so long as at least one of the items satisfies the filtering predicate (contains 'm'). Should not this query instead return only those items that satisfy the predicate? If this behavior of the API is intended, then it strikes me as both unintuitive and contradictory to the promise of GraphQL to "give clients the power to ask for exactly what they need and nothing more".
Of course, the intended filtered results can be obtained in one-shot if the query is crafted correctly (i.e., in one relationship direction and not its inverse). Nevertheless, this observation breaks down when querying multiple related tables where an interim table is related to two other tables on the one-side of a relationship with one of the tables and on the many side of a relationship with the other table in the query. In that situation, either multiple queries are required, or the query must be encapsulated in a stored procedure, or subsequent client-side filtering must be employed to properly filter the result set.
Version
8.52
What database are you using?
Azure SQL
What hosting model are you using?
Local (including CLI)
Which API approach are you accessing DAB through?
GraphQL
Relevant log output
No response
Code of Conduct