Make throwing exceptions on unknown filters optional #1014
Conversation
This file contains hidden or 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
|
Totally agree on this approach... |
|
Could you add a test for the new function? |
|
Regarding the tests: will do. Should similar functionality be added for the other actions (sorts, includes) as well to keep the functionality uniform? |
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.
Sometimes, I come across a situation where I want to apply filters on multiple queries in one request. Each of the filters in the request may only apply to one of the queries. In that case, an
InvalidFilterQuerywill be thrown because not all filters are valid for all queries.I'm aware that this can be disabled with the
query-builder.disable_invalid_filter_query_exceptionconfig variable, but I'd like to keep throwing exceptions in most cases, but when one of these special cases arise, disable it on theQueryBuilderlevel.This should keep the current default functionality as-is and not introduce any breaking changes. If this is not suitable for the project or you may have any other questions, please let me know.