-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issue where the query planner was incorrectly not querying `__typ… #2366
Fix issue where the query planner was incorrectly not querying `__typ… #2366
Conversation
…ename` in a subgraph fetch when `@interfaceObject` is involved When we fetch data for abstract types (typically interface), we usually need to make sure that `__typename` is queried as the code that post-process responses may have to know the concrete type of an object in the response (to know if it should be included or not). There is a method that `__typename` for abstract types in fetch selections, but that method was not doing it for fragments for some reason (a oversight really). While this never created an issue before, this is now problematique in some case with `@interfaceObject` and so this commit ensure `__typename` is always added, even for fragments. Working on this issue, I also noticed that the part of the code that in the query planner that eliminates useless fetches (sometimes, due to how the query planner process work, some fetches are created but end up not querying anything useful (meaning that they only query things already queried)) had not been updated for `@interfaceObject` and was not doing its job in some case. This lead to query plans including unecessary fetches (which can have a non-negligible impact). This commit also fix that issue.
👷 Deploy request for apollo-federation-docs pending review.Visit the deploys page to approve it
|
🦋 Changeset detectedLatest commit: 18b1b40 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
@@ -881,6 +881,7 @@ describe('buildQueryPlan', () => { | |||
__typename | |||
... on Image { | |||
... on NamedObject @include(if: $b) { | |||
__typename |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to reviewers: there is a handful of cases, like this one, where the change of this commit adds a __typename
that wasn't there before, even though it's technically redundant (we already ask for the __typename
of this object a few lines above). Imo, that's fine and it's not worth being bothered by: it doesn't happen much and asking for __typename
is always pretty cheap, so this probably have no measurable effect. We can try to avoid this kind of duplication later if that bother someone and we have spare cycles, but the check implementation may create more inefficiencies in query planner than it saves at execution.
…ename
in a subgraph fetch when
@interfaceObject` is involvedWhen we fetch data for abstract types (typically interface), we usually need to make sure that
__typename
is queried as the code that post-process responses may have to know the concrete type of an object in the response (to know if it should be included or not).There is a method that
__typename
for abstract types in fetch selections, but that method was not doing it for fragments for some reason (a oversight really). While this never created an issue before, this is now problematique in some case with@interfaceObject
and so this commit ensure__typename
is always added, even for fragments.Working on this issue, I also noticed that the part of the code that in the query planner that eliminates useless fetches (sometimes, due to how the query planner process work, some fetches are created but end up not querying anything useful (meaning that they only query things already queried)) had not been updated for
@interfaceObject
and was not doing its job in some case. This lead to query plans including unecessary fetches (which can have a non-negligible impact). This commit also fix that issue.