[jira] [Created] (DRILL-3347) Resolve: ResultSet.getObject(...) for VARCHAR returns ...hadoop.io.Text, not String

["Daniel Barclay (Drill) (JIRA)" <ji...@apache.org>]

Daniel Barclay (Drill) created DRILL-3347:
---------------------------------------------

             Summary: 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
            Reporter: Daniel Barclay (Drill)


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 JDBC.

If this behavior is intentional (presumably for optimization), we should resolve how it fits in JDBC type-mapping rules.
 

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.)
 

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 types).)

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.
 

(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
(v6.3.4#6332)