[
https://issues.apache.org/jira/browse/CALCITE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251371#comment-14251371
]
Julian Hyde commented on CALCITE-534:
-------------------------------------
I don't recall why we have type and fieldType, but I'm pretty sure there was a
good reason - and I'm sure a test case would break if we tried to combine them.
getClassName should be fairly simple - it basically indicates the "user type"
of the returned value, and hence the preferred JDBC method (e.g. getInt or
getString or getTimestamp etc.). Nothing to do with the internal type (e.g.
internally we handle SQL TIMESTAMP values as Java long values, but externally
they are java.sql.Timestamp.) That user type should follow in a very
predictable way from the SQL type.
It should be based on AvaticaType.type, i.e. ColumnMetaData.type.type. Because
we can derive from the type id, we don't need a AvaticaType.className field
(until we support custom type mappings).
> Missing implementation of ResultSetMetaData.getColumnClassName(int)
> -------------------------------------------------------------------
>
> Key: CALCITE-534
> URL: https://issues.apache.org/jira/browse/CALCITE-534
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.0.0-incubating
> Reporter: Knut Forkalsrud
> Assignee: Julian Hyde
> Attachments: resultsetmetadata.patch
>
>
> We are running into an obstacle using a very simple Calcite in memory table.
> It manifests itself in getting the column classname from ResultSetMetaData.
> It seems easy enough to fix, at least for our purposes. Here is a proposed
> patch relative to Git master within the last hour:
> {noformat}
> diff --git
> a/avatica/src/main/java/org/apache/calcite/avatica/ColumnMetaData.java
> b/avatica/src/main/java/org/apache/calcite/avatica/ColumnMetaData.java
> index 102590e..fca92b4 100644
> --- a/avatica/src/main/java/org/apache/calcite/avatica/ColumnMetaData.java
> +++ b/avatica/src/main/java/org/apache/calcite/avatica/ColumnMetaData.java
> @@ -106,7 +106,8 @@ public ColumnMetaData(
> this.readOnly = readOnly;
> this.writable = writable;
> this.definitelyWritable = definitelyWritable;
> - this.columnClassName = columnClassName;
> + this.columnClassName = columnClassName != null
> + ? columnClassName : type.representation.clazz.getName();
> }
>
> private static <T> T first(T t0, T t1) {
> diff --git
> a/core/src/test/java/org/apache/calcite/test/TableInRootSchemaTest.java
> b/core/src/test/java/org/apache/calcite/test/TableInRootSchemaTest.java
> index 58ebe99..3898422 100644
> --- a/core/src/test/java/org/apache/calcite/test/TableInRootSchemaTest.java
> +++ b/core/src/test/java/org/apache/calcite/test/TableInRootSchemaTest.java
> @@ -77,6 +77,8 @@
> assertThat(resultSetMetaData.getColumnName(1), equalTo("A"));
> assertThat(resultSetMetaData.getTableName(1), equalTo("SAMPLE"));
> assertThat(resultSetMetaData.getSchemaName(1), nullValue());
> + assertThat(resultSetMetaData.getColumnClassName(1),
> + equalTo("java.lang.String"));
> // Per JDBC, column name should be null. But DBUnit requires every column
> // to have a name, so the driver uses the label.
> assertThat(resultSetMetaData.getColumnName(2), equalTo("EXPR$1"));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
