drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Barclay (Drill) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-3347) Resolve: ResultSet.getObject(...) for VARCHAR returns ...hadoop.io.Text, not String
Date Tue, 04 Aug 2015 17:59:05 GMT

    [ https://issues.apache.org/jira/browse/DRILL-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654053#comment-14654053

Daniel Barclay (Drill) commented on DRILL-3347:

Notes re intent and precedents:

The ProGuard configuration in {{./exec/jdbc-all/pom.xml}} specifically excludes {{org.apache.hadoop:hadoop-common}}
(whose Jar file provides {{org.apache.hadoop.io.Text}}), so it seems that returning {{org.apache.hadoop.io.Text}}
rather than {{String}} from {{getObject(...)}} was not intended.

The SQLAccessor subclasses for JDBC convert internal Joda Time types into {{java.sql.Time}},
{{java.sql.Date}}, and {{java.sql.Timestamp}} types, following the JDBC specification, so,
again, it seems that returning non-JDBC-standard types (e.g., {{org.apache.hadoop.io.Text}})
is not intended.

In the SqlAccessors template, 

> Resolve: ResultSet.getObject(...) for VARCHAR returns ...hadoop.io.Text, not String
> -----------------------------------------------------------------------------------
>                 Key: DRILL-3347
>                 URL: https://issues.apache.org/jira/browse/DRILL-3347
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Client - JDBC
>            Reporter: Daniel Barclay (Drill)
>            Assignee: Daniel Barclay (Drill)
>             Fix For: 1.2.0
> For SQL type CHARACTER VARYING, ResultSet methods [getObject(int)|http://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getObject-int-]
and [getObject(String)|http://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getObject-String-]
return an org.apache.hadoop.io.Text object, not a java.lang.String object, as specified by
> If this behavior is intentional (presumably for optimization), we should resolve how
it fits in JDBC type-mapping rules.
> &nbsp;
> JDBC does allow custom mapping from SQL types to Java types.  However, Drill's getObject
behaves as above by default, although JDBC says that by default there are no custom mappings.
> Additionally, the JDBC driver does not implement Connection.getTypeMap() or Connection.setTypeMap(...),
which means that the client can neither ask the driver what class getObject(...) will use
for CHARACTER VARYING, or tell it to revert to the standard mapping.
> (Also, JDBC's wording about custom mappings seems to allow it only for user-defined types,
not predefined types (such as CHARACTER VARYING), but it's not clear whether that was intended,
and much of the JDBC specification is ambiguous--and some is clearly wrong.)
> &nbsp;
> Choices regarding the return values/type of  getObject(int)/getObject(String) include:
> 1.  Not changing the behavior (but documenting it).  This is non-compliant with JDBC
in several ways (non-standard mapping, no reporting of mapping via getMap, no changing back
to standard via setMap).
> 2.  Implementing getMap enough to support at least reporting of the actual mapping.
> 3.  Implementing setMap as well as getMap, enough* to support switching to the standard
mapping (and back to the custom mapping).  (*This option does not require fully implementing
the general custom mapping allowed by JDBC (e.g., for arbitrary user-defined SQL and Java
> 4.  Defaulting to the standard mapping (in addition to adding setMap and getMap), to
support starting off in the standard default state.  (This choice is the compliant with the
JDBC specification.)
> It is not clear whether there are any other cases that need to be resolved.
> &nbsp;
> (For most SQL types, Drill's getObject already returns the expected types.  For interval
types, getObject's returning of org.joda.time.Period objects doesn't conflict with any expected
type because there is no expected type.  (JDBC (as of 4.2) doesn't address interval types.))

This message was sent by Atlassian JIRA

View raw message