refactor: change error type for "no statement" #11411
Merged
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
crepererum
changed the title
crepererum
force-pushed
the
crepererum/amend_pr11394
branch
from
1ea55ee to
1f2ced0
Compare
comphead
reviewed
Jul 11, 2024
comphead
approved these changes
Jul 11, 2024
Amends apache#11394 (sorry, I should have reviewed that). While reporting "not implemented" for "multiple statements" seems reasonable, I think the user should get a plan error (which roughly translates to "invalid argument") if they don't provide any statement. I don't see any reasonable way to support "no statement" ever, hence "not implemented" seems like a wrong promise.
crepererum
force-pushed
the
crepererum/amend_pr11394
branch
from
1f2ced0 to
cbb1c9a
Compare
alamb
reviewed
Jul 11, 2024
| DataFusionError::NotImplemented( | ||
| "No SQL statements were provided in the query string".to_string(), | ||
| ) | ||
| plan_datafusion_err!("No SQL statements were provided in the query string") |
Lordworms
pushed a commit
to Lordworms/arrow-datafusion
that referenced
this pull request
Jul 12, 2024
Amends apache#11394 (sorry, I should have reviewed that). While reporting "not implemented" for "multiple statements" seems reasonable, I think the user should get a plan error (which roughly translates to "invalid argument") if they don't provide any statement. I don't see any reasonable way to support "no statement" ever, hence "not implemented" seems like a wrong promise.
findepi
pushed a commit
to findepi/datafusion
that referenced
this pull request
Jul 16, 2024
Amends apache#11394 (sorry, I should have reviewed that). While reporting "not implemented" for "multiple statements" seems reasonable, I think the user should get a plan error (which roughly translates to "invalid argument") if they don't provide any statement. I don't see any reasonable way to support "no statement" ever, hence "not implemented" seems like a wrong promise.
xinlifoobar
pushed a commit
to xinlifoobar/datafusion
that referenced
this pull request
Jul 17, 2024
Amends apache#11394 (sorry, I should have reviewed that). While reporting "not implemented" for "multiple statements" seems reasonable, I think the user should get a plan error (which roughly translates to "invalid argument") if they don't provide any statement. I don't see any reasonable way to support "no statement" ever, hence "not implemented" seems like a wrong promise.
xinlifoobar
pushed a commit
to xinlifoobar/datafusion
that referenced
this pull request
Jul 18, 2024
Amends apache#11394 (sorry, I should have reviewed that). While reporting "not implemented" for "multiple statements" seems reasonable, I think the user should get a plan error (which roughly translates to "invalid argument") if they don't provide any statement. I don't see any reasonable way to support "no statement" ever, hence "not implemented" seems like a wrong promise.
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.
Which issue does this PR close?
Amends #11394 (sorry, I should have reviewed that).
Rationale for this change
While reporting "not implemented" for "multiple statements" seems reasonable, I think the user should get a plan error (which roughly translates to "invalid argument") if they don't provide any statement. I don't see any reasonable way to support "no statement" ever, hence "not implemented" seems like a wrong promise.
What changes are included in this PR?
The user now gets a plan error instead of "no implemented" if no statement was provided.
Are these changes tested?
Adjusted existing test.
Are there any user-facing changes?
Improved error type. Esp. if the user converts that error type into a gRPG/HTTP error (e.g. IOx does this) then you can expect a more appropriate outcome.