Review Board 1.7.22


Modify troubleshooting section to reflect use of '--driver' flag with connection managers

Review Request #9493 - Created Feb. 18, 2013 and updated

Linden Hillenbrand
Sqoop-626
Reviewers
Sqoop
jarcec, kate
sqoop-trunk
Correcting Sqoop user-guide troubleshooting section to add verbage to make sure users are aware that '--driver' flag should not be used with connection managers as it will default to the default connection manager if that flag is set.
Standard tests run, docs built successfully.

Diff revision 2 (Latest)

1 2
1 2

  1. src/docs/user/troubleshooting.txt: Loading...
src/docs/user/troubleshooting.txt
Revision be43541 New Change
[20] 234 lines
[+20]
235
----
235
----
236

    
   
236

   
237
Solution: Omit the option --driver oracle.jdbc.driver.OracleDriver and then
237
Solution: Omit the option --driver oracle.jdbc.driver.OracleDriver and then
238
re-run the Sqoop command.
238
re-run the Sqoop command.
239

    
   
239

   

    
   
240
Issues with using --driver flag with Connection Managers

    
   
241
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    
   
242

   

    
   
243
While working with Oracle, DB2, HSQLDB, MySQL, PostgresSQL, or Microsoft SQL Server, 

    
   
244
you may encounter a problem when the Sqoop command explicitly specifies the 

    
   
245
--driver <driver name> option. That is, when the driver option is included in the 

    
   
246
Sqoop command, the built-in connection manager selection defaults to the generic 

    
   
247
connection manager, which causes this issue. If the driver option is not specified, 

    
   
248
the built-in connection manager selection mechanism selects the appropriate specific 

    
   
249
connection manager which generates valid SQL and uses the driver "oracle.jdbc.OracleDriver", 

    
   
250
"com.ibm.db2.jcc.DB2Driver", "org.hsqldb.jdbcDriver", "com.mysql.jdbc.Driver", 

    
   
251
"org.postgresql.Driver", or "com.microsoft.sqlserver.jdbc.SQLServerDriver" respectively.

    
   
252

   
240
MySQL: Import of TINYINT(1) from MySQL behaves strangely
253
MySQL: Import of TINYINT(1) from MySQL behaves strangely
241
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
254
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
242
Problem: Sqoop is treating TINYINT(1) columns as booleans, which is for example
255
Problem: Sqoop is treating TINYINT(1) columns as booleans, which is for example
243
causing issues with HIVE import. This is because by default the MySQL JDBC connector
256
causing issues with HIVE import. This is because by default the MySQL JDBC connector
244
maps the TINYINT(1) to java.sql.Types.BIT, which Sqoop by default maps to Boolean.
257
maps the TINYINT(1) to java.sql.Types.BIT, which Sqoop by default maps to Boolean.
245

    
   
258

   
246
Solution: A more clean solution is to force MySQL JDBC Connector to stop
259
Solution: A more clean solution is to force MySQL JDBC Connector to stop
247
converting TINYINT(1) to java.sql.Types.BIT by adding +tinyInt1isBit=false+ into your
260
converting TINYINT(1) to java.sql.Types.BIT by adding +tinyInt1isBit=false+ into your
248
JDBC path (to create something like +jdbc:mysql://localhost/test?tinyInt1isBit=false+).
261
JDBC path (to create something like +jdbc:mysql://localhost/test?tinyInt1isBit=false+).
249
Another solution would be to explicitly override the column mapping for the datatype
262
Another solution would be to explicitly override the column mapping for the datatype
250
TINYINT(1) column. For example, if the column name is foo, then pass the following
263
TINYINT(1) column. For example, if the column name is foo, then pass the following
251
option to Sqoop during import: --map-column-hive foo=tinyint. In the case of non-Hive
264
option to Sqoop during import: --map-column-hive foo=tinyint. In the case of non-Hive
252
imports to HDFS, use --map-column-java foo=integer.
265
imports to HDFS, use --map-column-java foo=integer.
  1. src/docs/user/troubleshooting.txt: Loading...