[
https://issues.apache.org/jira/browse/PHOENIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563604#comment-15563604
]
ASF GitHub Bot commented on PHOENIX-3345:
-----------------------------------------
Github user lomoree commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/215#discussion_r82688259
--- Diff:
phoenix-core/src/main/java/org/apache/calcite/jdbc/PhoenixCalciteFactory.java
---
@@ -161,6 +162,29 @@ public Object apply(
}));
}
+ public CalciteStatement createStatement(String sql, int
resultSetType, int resultSetConcurrency, int resultSetHoldability) throws
SQLException {
+ try {
+ return super.createStatement(resultSetType,
resultSetConcurrency, resultSetHoldability);
+ } catch (SQLException e) {
+ if (e.getCause().getCause() instanceof SQLException) {
+ throw (SQLException) e.getCause().getCause();
--- End diff --
I wondered about this myself. While I didn't encounter any cases where
exception levels varied, it's a good idea to account for it. Will make these
changes, thanks @maryannxue
> SQLException code's not propagating as expected
> -----------------------------------------------
>
> Key: PHOENIX-3345
> URL: https://issues.apache.org/jira/browse/PHOENIX-3345
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Eric Lomore
> Assignee: Eric Lomore
> Attachments: variablestate.png
>
>
> Perhaps this is intended by Calcite, but when errors are thrown by execute()
> functions the error code that is initially thrown (say 1000) does not make
> its way to the final SQLException on top.
> This is prevalent in multiple tests throughout QueryCompilerTest.java. One
> such example is included below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
