[
https://issues.apache.org/jira/browse/DRILL-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3347:
------------------------------------------
Priority: Critical (was: Major)
> 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: Deneche A. Hakim
> Priority: Critical
> 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 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)
