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] [Updated] (DRILL-3347) Resolve: ResultSet.getObject(...) for VARCHAR returns ...hadoop.io.Text, not String
Date Tue, 18 Aug 2015 01:25:45 GMT

     [ https://issues.apache.org/jira/browse/DRILL-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Daniel Barclay (Drill) updated DRILL-3347:
    Assignee: Parth Chandra  (was: Daniel Barclay (Drill))

> 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: Parth Chandra
>             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