sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ferenc Szabo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SQOOP-3241) ImportAllTablesTool uses the same SqoopOptions object for every table import
Date Mon, 18 Dec 2017 15:59:00 GMT

    [ https://issues.apache.org/jira/browse/SQOOP-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295166#comment-16295166

Ferenc Szabo commented on SQOOP-3241:

Hi [~vasas],

after looking at the SqoopOptions class in the apache package, we might reconsider what we
want to do here.

This class has 125 fields at the moment...
 - That means implementing a copy constructor (as suggested in Effective Java), is a little
bit too much effort.

Our two main other options, besides clone are:
- Serialization
- Reflection

However, I believe these would just add more complexity.

I wonder why these properties are not in a HashMap in the first place?

[This article|https://vyazelenko.com/2013/10/29/copy-object-in-java-performance-comparison/]
sums up our options quite nicely (though from the perspective of performance).

The apache EqualsBuilder returns false, by the way:
EqualsBuilder.reflectionEquals(options, clonedOption)
(Of course, this does not violate the contract of clone.)

In any case, refactoring this clone method seems to be a lot of effort, so let's sync before
I proceed any further.

> ImportAllTablesTool uses the same SqoopOptions object for every table import
> ----------------------------------------------------------------------------
>                 Key: SQOOP-3241
>                 URL: https://issues.apache.org/jira/browse/SQOOP-3241
>             Project: Sqoop
>          Issue Type: Bug
>    Affects Versions: 1.4.6
>            Reporter: Szabolcs Vasas
>            Assignee: Ferenc Szabo
> ImportAllTablesTool queries the list of tables from the database and invokes ImportTool#importTable
method for each table.
> The problem is that it passes the same SqoopOptions object in every invocation and since
SqoopOptions is not immutable this can lead to issues.
> For example in case of Parquet imports the CodeGenTool#generateORM method modifies the
className field of the SqoopOptions object which is then remains the same for all the subsequent
table imports and can cause job failures.
> One solution could be to create a new SqoopOptions object with the same field values
for every ImportTool#importTable invocation.

This message was sent by Atlassian JIRA

View raw message