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

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Fix Version/s: 1.2.0
• Component/s: Client - JDBC
• Assignee: Daniel Barclay
• Reporter: Daniel Barclay
• Created: 23/Jun/15 22:16
• Updated: 15/Sep/15 16:47
• Resolved: 15/Sep/15 12:43

Description

For SQL type CHARACTER VARYING, ResultSet methods getObject(int) and 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.))

Issue Links

• is required by: DRILL-2489 Accessing Connection, Statement, PreparedStatement after they are closed should throw a SQLException
• supercedes: DRILL-2482 JDBC : calling getObject when the actual column type is 'NVARCHAR' results in NoClassDefFoundError
• supercedes: DRILL-3658 Missing org.apache.hadoop in the JDBC jar
• links to: https://github.com/apache/drill/pull/111