[SPARK-12533][SQL] hiveContext.table() throws the wrong exception #10529
Conversation
Avoiding the the No such table exception and throwing analysis exception as per the bug: SPARK-12533
|
OK to test |
There was a problem hiding this comment.
this will fail style checker. you will need to add a space before and after +.
There was a problem hiding this comment.
Sure @rxin .Will update the fix and create a new pull request
Incorporating the review comments
|
@rxin I have updated the style check difference ,you mentioned. and committed to my branch. And I see it is reflected here in this same pull request. Could you please review? |
|
Test build #2281 has finished for PR 10529 at commit
|
|
working on the updates |
|
I think, there would be a reference update in Analyzer.scala as we discussed @thomastechs |
AnalysisException is updated as per the bug fic mentions SPARK-12533
|
@jayadevanmurali : Yes, modifying the files which has reference to the code fix, as well. |
As the exception type returned from the lookupRelation method is changed to AnalysisException, it is updated here also.
Updating the test case methods corresponding the bug fix [SPARK-12438]
thomastechs
changed the title
|
Test build #2288 has finished for PR 10529 at commit
|
Removed the AnalysisException class import command, as it throws (hidden) warning. The Analysis Exception is already available in this package
Reverting to change to previous state, because the relevant test cases are to be triggered.
|
Test build #2299 has finished for PR 10529 at commit
|
|
I've merged this. Thanks. |
There was a problem hiding this comment.
Does this mean that NoSuchTableException is not used anywhere? We should probably get rid of it then. Though, I think I'd have a slight preference for keeping a special exception internally. The point of this extra control flow is so that we can attach line position information to this specific exception in the analyzer.
There was a problem hiding this comment.
@marmbrus Shouldn't we have fixed this issue by marking the relation unresolved and let the analyzer generate a proper AnalysisException ? If we were to use the catalog interface for some other purpose like tooling etc keeping the generic catalog exceptions would have been better ?
6 participants
Avoiding the the No such table exception and throwing analysis exception as per the bug: SPARK-12533