Review Board 1.7.22


SQOOP-890: ClassWriter Generates setField Casts Based on the Output Type, not the Input Type

Review Request #12806 - Created July 22, 2013 and updated

Nick White
Reviewers
Sqoop
sqoop-trunk
Sqoop should be more flexible when converting between number types.
Unit test included.
Review request changed
Updated (July 24, 2013, 5:44 p.m.)
You're right, it's not essential due to map-columns, but it's really quite convenient when you don't know what types a JDBC driver will map some of the more odd SQL types to (e.g. reals, decimals & numerics - even HSQLDB 1.8 returns doubles for a float column). Sqoop should definitely support silent widening (e.g. storing an int in a SQL long-typed column) but I understand your point re: narrowing. Would a warning when converting be sufficient? Or would you prefer that narrowing types had to be given explicitly on the command line? I don't know any libraries of the top of my head that will narrow (e.g.) a float to a double if that narrowing doesn't result in data loss. I've updated the patch to add a widening and narrowing case, both of which fail in 1.4.3 and pass with the patch.

Thanks -
Posted (July 28, 2013, 12:51 a.m.)
I totally  see your point Nick. I still do not feel entirely comfortable about doing some data conversions without explicit user permission on a stable branch in potentially backward incompatible manner. Do you think that it would make sense to enable this behavior conditionally? We could add a new command line argument allowing "relaxed" and possibly dangerous conversions. This way user have to be explicit that it's acceptable behavior.