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)
