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
