You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2015/03/26 23:46:54 UTC
[jira] [Commented] (CALCITE-647) Avatica cursor type cast for
number cause exception in AvaticaResultSet
[ https://issues.apache.org/jira/browse/CALCITE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382864#comment-14382864 ]
Julian Hyde commented on CALCITE-647:
-------------------------------------
I agree with your analysis of the cause, but I don't agree with your solution. ByteAccessor is an accessor for values that are known to be of type Byte, so it doesn't need to be fixed; you shouldn't be using it for JSON data. I think you should be using a different accessor, maybe like NumberAccessor, that doesn't make assumptions about the exact type of the values.
Note I added the "boolean json" field to LocalService recently. That was for a very similar purpose.
This fix is not complete without a test case. Without one, we will very easily regress.
I don't think there is a test suite in Avatica that serializes requests and responses to JSON and back. (It doesn't need to send them over HTTP, so it can run in a single thread in a single JVM.) That would have discovered this issue, and probably several similar issues. Maybe you could create a variant of RemoteDriverTest that does this.
Can you also please check whether this issue exists for parameters? I think if you have a long or double parameter and set it to 0, the value will arrive at the server as an int. The server needs to be able to handle that.
[~ndimiduk] Can you please review the tests in Avatica, plus CalciteRemoteDriverTest. If the tests don't have coverage for basic functionality (all data types, all request/response types, over all transports) please log jira cases. (Now we have JdbcMeta and the scott JDBC database, we could consider moving much of CalciteRemoteDriverTest into Avatica; CalciteRemoteDriverTest would be just a sub-class of that test that uses CalciteMeta rather than JdbcMeta.)
> Avatica cursor type cast for number cause exception in AvaticaResultSet
> -----------------------------------------------------------------------
>
> Key: CALCITE-647
> URL: https://issues.apache.org/jira/browse/CALCITE-647
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.1.0-incubating
> Reporter: Xavier FH Leong
> Assignee: Julian Hyde
> Labels: avatica
> Attachments: CALCITE-647-cursor-numberTypeCast.patch
>
>
> After the result are deserialized from JSON on remote side, the object is not with it's original type, forcing casing of box type Long on Integer raise exception.
> For all box number, it will type cast to Number and extract using the Number method instead.
> 2015-03-26 15:49:48,154 [Thread-10] ERROR net.sourceforge.squirrel_sql.fw.sql.ResultSetReader - Error reading column data, column index = 3
> java.lang.ClassCastException: java.lang.Integer incompatible with java.lang.Long
> at org.apache.calcite.avatica.util.AbstractCursor$LongAccessor.getLong(AbstractCursor.java:483)
> at org.apache.calcite.avatica.AvaticaResultSet.getLong(AvaticaResultSet.java:252)
> at net.sourceforge.squirrel_sql.fw.datasetviewer.cellcomponent.DataTypeLong.readResultSet(DataTypeLong.java:365)
> at net.sourceforge.squirrel_sql.fw.datasetviewer.cellcomponent.CellComponentFactory.readResultSet(CellComponentFactory.java:488)
> at net.sourceforge.squirrel_sql.fw.sql.ResultSetReader.doContentTabRead(ResultSetReader.java:613)
> at net.sourceforge.squirrel_sql.fw.sql.ResultSetReader.readRow(ResultSetReader.java:184)
> at net.sourceforge.squirrel_sql.fw.datasetviewer.ResultSetDataSet.createRow(ResultSetDataSet.java:237)
> at net.sourceforge.squirrel_sql.fw.datasetviewer.ResultSetDataSet._setResultSet(ResultSetDataSet.java:203)
> at net.sourceforge.squirrel_sql.fw.datasetviewer.ResultSetDataSet.setSqlExecutionTabResultSet(ResultSetDataSet.java:126)
> at net.sourceforge.squirrel_sql.client.session.mainpanel.SQLExecutionHandler.sqlResultSetAvailable(SQLExecutionHandler.java:410)
> at net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.processResultSet(SQLExecuterTask.java:542)
> at net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.processQuery(SQLExecuterTask.java:407)
> at net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.run(SQLExecuterTask.java:205)
> at net.sourceforge.squirrel_sql.fw.util.TaskExecuter.run(TaskExecuter.java:82)
> at java.lang.Thread.run(Thread.java:853)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)