Don't check for a convention when not one isn't needed #7019
Conversation
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
When setting up filtering and sorting with UseFiltering and UseSorting, there are 3 different code paths that are traversed. Prior to this change, all 3 of them required that a convention be registered otherwise an exception would occur. However, for both filtering and sorting, only 1 of the code paths actually needs a convention. The other two do not use the convention at all. This commit changes the filtering and sorting object field descriptor extensions to attempt to get a convention only within the block of code that requires a convention. By making this small change, the other two code paths that do not require a convention will no longer encounter an exception. Instead, filtering and sorting can be set up as expected. This commit partially addresses ChilliCream#6983. We are able locally, with these changes applied, to use filtering and sorting from a type module by calling the versions of `UseFiltering` and `UseSorting` that take a type. Without the changes in this commit, we get the "no convention registered" error. This change does not close ChilliCream#6983 as it is still possible to encounter the "no convention registered" exception and its suggested remedy of "Call `AddFiltering()` on the schema builder" doesn't work. From what we can see, and have detailed in ChilliCream#6983, no conventions registered with the schema builder either directly or the defaults provided by `AddFiltering` and `AddSorting` are available at the time that a type module is run. The result of this commit is to allow the usage `UseFiltering` and `UseSorting` with types created via a type module. The other option we are aware of is detailed by @jimitndiaye in ChilliCream#6975. Jimit routes around the convention problem by not using a convention at all in his custom middleware. A close examination of `UseFilteringInternal` at ChilliCream#6975 (reply in thread) will show this lack of convention usage as key to his fix. Instead of going the custom middleware route, we made these two small changes to Hot Chocolate. We prefer this approach.
|
My editor made a couple extraneous whitespace changes. Let me know if you would like me to revert them. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7019 +/- ##
==========================================
- Coverage 72.85% 70.16% -2.69%
==========================================
Files 2585 2585
Lines 129190 129491 +301
==========================================
- Hits 94115 90857 -3258
- Misses 35075 38634 +3559
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@michaelstaib ping to get your attention on this per your comment #6983 (comment) |
|
@PascalSenn in #6983, @michaelstaib said you should be pinged about this. |
|
@SeanTAllen, sorry, I didn't have this on my radar! @michaelstaib, this looks good to me. It's just moving the convention resolution into the branch that actually needs it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When setting up filtering and sorting with UseFiltering and UseSorting, there are 3 different code paths that are traversed. Prior to this change, all 3 of them required that a convention be registered otherwise an exception would occur. However, for both filtering and sorting, only 1 of the code paths actually needs a convention. The other two do not use the convention at all.
This commit changes the filtering and sorting object field descriptor extensions to attempt to get a convention only within the block of code that requires a convention. By making this small change, the other two code paths that do not require a convention will no longer encounter an exception. Instead, filtering and sorting can be set up as expected.
This commit partially addresses #6983. We are able locally, with these changes applied, to use filtering and sorting from a type module by calling the versions of
UseFilteringandUseSortingthat take a type. Without the changes in this commit, we get the "no convention registered" error.This change does not close #6983 as it is still possible to encounter the "no convention registered" exception and its suggested remedy of "Call
AddFiltering()on the schema builder" doesn't work.From what we can see, and have detailed in #6983, no conventions registered with the schema builder either directly or the defaults provided by
AddFilteringandAddSortingare available at the time that a type module is run.The result of this commit is to allow the usage
UseFilteringandUseSortingwith types created via a type module. The other option we are aware of is detailed by @jimitndiaye in #6975. Jimit routes around the convention problem by not using a convention at all in his custom middleware. A close examination ofUseFilteringInternalat #6975 (reply in thread) will show this lack of convention usage as key to his fix. Instead of going the custom middleware route, we made these two small changes to Hot Chocolate. We prefer this approach.