You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "YeongWei (JIRA)" <ji...@apache.org> on 2015/09/24 18:37:04 UTC

[jira] [Commented] (CALCITE-705) AvaticaStatement execute method to support DML

    [ https://issues.apache.org/jira/browse/CALCITE-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14906609#comment-14906609 ] 

YeongWei commented on CALCITE-705:
----------------------------------

Hi [~julianhyde],

Sincerely apologize for the long delay on this matter! I am very sorry about it!

Please refer to the details below.

**Fixed Reported Exception during "mvn test"**
I have made attempts to look at the exception you have encountered about. It failed with the Unit Test(s) which attempts to test PreparedStatement without setting the bind variables, you may refer to the test method at `org.apache.calcite.avatica.RemoteDriverTest#testPrepareBindExecuteFetch`. I initially did not capture because my environment was using the JDK 1.7 and according to the method mentioned, it skips the test if it sees a JDK 1.7.

The exception bubbles up from a NPE. This is because when the bind variables werenot set, the `TypeValue[] parameterValue` variable will have null elements that is results in method invocation on null value.

The fix to this matter, a static method as `MetaImpl#checkParameterValueHasNul`l that is used in both `JdbcMeta#execute` and `CalciteConnectionImpl#enumerable` to check if parameterValue has null element then throw the exception of "unbound parameter"

**Fixes related to Exception propagation**
I have also fixed the sections below that I believe was not creation exception correctly,

`org.apache.calcite.avatica.AvaticaConnection#executeQueryInternal` should use the `e.getMessage()` during the `helper.createException(..)` call

`org.apache.calcite.avatica.jdbc.JdbcMeta#propagate` should create use `RuntimeException(e.getMessage())`

**Ignored Unit Test**
The Unit Tests below are ignore because it is using the `CalciteAssert#assertQuery` that uses the `executeQuery` to evaluate the DML s. This will now cause problems below the `executeQuery` strictly expects a `resultSet` but with the DML implementation here there will be no `resultSet` returned for DML. The proposal here is to change the `CalciteAssert#assertQuery` to used `execute()` instead of `executeQuery()`

1. `org.apache.calcite.test.JdbcFrontLinqBackTest#testInsert`
2. `org.apache.calcite.test.JdbcFrontLinqBackTest#testInsert2`

I have re-commited into the github, the same pull request can be used,
https://github.com/apache/incubator-calcite/pull/108

The commit is at,
https://github.com/yeongwei/incubator-calcite/commit/638947bd27f5fce1c7318661e6f5bc283f62bb2a?diff=split

I am currently using JDK 1.8 as below,
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Look forward to hear from you.

Thanks!

> AvaticaStatement execute method to support DML
> ----------------------------------------------
>
>                 Key: CALCITE-705
>                 URL: https://issues.apache.org/jira/browse/CALCITE-705
>             Project: Calcite
>          Issue Type: New Feature
>          Components: avatica
>            Reporter: YeongWei
>            Assignee: Julian Hyde
>             Fix For: next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)