----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/64715/ -----------------------------------------------------------
(Updated Dec. 27, 2017, 3:36 p.m.) Review request for Sqoop, Boglarka Egyed and Szabolcs Vasas. Changes ------- Hi Szabolcs, Thanks, nice hint there, with commenting out... :) So I've created a test called testCloneCopiesAggregateFields to cover every part of clone. This initializes the SqoopOptions with valid values and then checks whether clone copies the fields. I removed the testIsEqualToComparingFieldByFieldRecursivelyFail test, because I realized that testing for failure doesn't really make sense. A testcase like that doesn't really provide coverage for any change that introduces bugs. The only remaining problem I see, is that if somebody adds a new field to SqoopOptions, it's not ensured to be cloned, and it's not tested if it's cloned. I will look into adding a new testcase that initializes each field with a radom value, based on this post: http://tuhrig.de/create-random-test-objects-with-java-reflection/ Bugs: SQOOP-3241 https://issues.apache.org/jira/browse/SQOOP-3241 Repository: sqoop-trunk Description ------- SQOOP-3241 ========== TL;DR: The problem is that the ImportAllTablesTool passes the same SqoopOptions object in every importTable invocation. Since SqoopOptions is mutable, this can lead to errors. The solution: ------------ - SqoopOptions already implements Clonable. The solution uses the clone method to create a copy of SqoopOptions for each invocation. - I've also added unit tests for the clone function, and - Introduced a new (test-scoped) dependency, i.e. assertj, because it contains the isEqualToComparingFieldByFieldRecursively function Concerns: --------- - The Clonable interface is not recommended to be used by many sources, but it seems to be the lesser evil here. - - Since SqoopOptions has more than a hundred fields, a copy constructor would add a lot of code to be maintained. - - Implementing a copy constructor either through reflection or through serialization would add unwanted complexity. - - The issues with Clonable really arise when there is a class hierarchy; this won't be a problem for SqoopOptions, as it doesn't really make sense to extend this class. - I've just covered two tools with the unit tests, would we benefit from more coverage? - The added dependency (please check if the config looks ok), 2.8.0 is an older version, but this is because Sqoop is using Java 1.7 Diffs (updated) ----- ivy.xml 601aa015 ivy/libraries.properties 2ef04f4f src/java/org/apache/sqoop/tool/ImportAllTablesTool.java d6d9f604 src/test/org/apache/sqoop/TestSqoopOptions.java 6d55c337 Diff: https://reviews.apache.org/r/64715/diff/2/ Changes: https://reviews.apache.org/r/64715/diff/1-2/ Testing ------- unit tests and 3rd party integration tests com.cloudera.sqoop.manager.OracleExportTest had an error in the first run, but passed in the second. It just seems flaky. Thanks, Fero Szabo
