-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fully eliminate the concept of heuristic fragment matching.
Although we removed the FragmentMatcher abstraction in PR #5073, and the HeuristicFragmentMatcher no longer exists, we kept trying to match fragments whenever all their fields matched, even if the fragment type condition was not satisfied by the __typename of the object in question. I recently came to appreciate just how harmful this best-effort matching can be, when I realized that it means we call executeSelectionSet (on the reading side) and processSelectionSet (on the writing side) for every unmatched fragment, and then just throw away the result if any fields are missing, but not before recording those fields as missing in a weaker way than usual, using the ExecResultMissingField.tolerable boolean. Not only is this strategy potentially costly for queries with lots of fragments that really should not match, it also only ever made sense on the writing side, where the fields of the fragment can be compared to the fields of an incoming result object, so the presence of all the fragment's fields is a pretty good indication that the fragment matched. On the reading side, we're comparing the fields of the fragment to all the fields we've written into the cache so far, which means heuristic fragment matching is sensitive to the whole history of cache writes for the entity in question, not just the current query. We could eliminate heuristic fragment matching just for reading, but then we'd have to tell people to pass possibleTypes to the InMemoryCache constructor (the correct, non-heuristic solution), which would make heuristic fragment matching unnecessary on the writing side, too, so we might as well completely eliminate heuristic matching altogether.
- Loading branch information
Showing
4 changed files
with
15 additions
and
29 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters