Thanks Julian. Jira case 563 created for this => https://issues.apache.org/jira/browse/CALCITE-563
How much time does it usually take for issue like this to be resolved ? Rgds, jay On Wed, Jan 21, 2015 at 1:08 AM, Julian Hyde <[email protected]> wrote: > Prepared statements are implemented, but not very thoroughly tested (see > JdbcTest.testPreparedStatement), and you've hit a bug. Calcite is trying to > push the bind variable down to the JDBC data source. (Pretty clever, huh?) > Except that it doesn't know how to generate the SQL. > > Can you log a jira case for this please? > > Julian > > > > On Jan 20, 2015, at 2:43 AM, Jiunn Jye Ng <[email protected]> wrote: > > > > Hi, > > > > When testing Calcite Jdbc Adaptor on prepared statement with bind > variable, > > > > sql = "select * from EMPS where EMPNO > ?" > > val ps = connection.prepareStatement(sql); > > ps.setInt(1, 1) > > rs = ps.executeQuery() > > > > Calcite fail the execution with error > > > > Caused by: java.lang.ClassCastException: > > org.apache.calcite.rex.RexDynamicParam incompatible with > > org.apache.calcite.rex.RexCall > > at > > > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:216) > > > > This is due to DYNAMIC_PARAM which are not implemented in > > JdbcImplementor$Context.toSql method. > > > > After quickly mocking up the support for DYNAMIC_PARAM, the execution is > > now failing with parameter not set from the external database. > > > > Caused by: org.h2.jdbc.JdbcSQLException: Parameter "#1" is not set; > > SQL statement: > > > > So I discovered it take much more than a few line of code changes to > > support bind variable. > > > > Does Calcite plan to support bind variable in JdbcAdaptor ? > > > > > > Thank you. > > > > Rgds, > > jay > >
