[jira] [Updated] (SQOOP-3320) Commit behaviour leads to exceptions on read-only database
[
https://issues.apache.org/jira/browse/SQOOP-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tijmen R updated SQOOP-3320:
Attachment: SQOOP-3320.patch
> Commit behaviour leads to exceptions on read-only database
> --
>
> Key: SQOOP-3320
> URL: https://issues.apache.org/jira/browse/SQOOP-3320
> Project: Sqoop
> Issue Type: Bug
> Components: connectors/generic
>Affects Versions: 1.4.7
>Reporter: Tijmen R
>Priority: Major
> Labels: newbie
> Attachments: SQOOP-3320.patch
>
>
> The current Sqoop behaviour is to do a commit after having retrieved the
> results of a query. This leads to errors when the database (or the
> connection) is in read-only mode.
> Example stack traces:
> {code:java}
> ERROR manager.SqlManager: SQLException closing ResultSet:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only
> at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
> at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
> {code}
> {code:java}
> tool.EvalSqlTool: SQL exception executing statement:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
> org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
> org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
> org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
> org.apache.sqoop.Sqoop.run(Sqoop.java:147)
>
> {code}
>
> When using _sqoop eval_, it is not a major issue since it happens after the
> data is already fetched and displayed. When using _sqoop import_ however, the
> spawned mapreduce jobs all fail, so this is blocking the whole import.
> This commit behaviour exists in several methods, at least the following:
> org.apache.sqoop.tool.EvalSqlTool::run (line 78)
> org.apache.sqoop.mapreduce.db.DBRecordReader::close (line 169)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForRawQuery (line 182)
> org.apache.sqoop.manager.SqlManager::getColumnInfoForRawQuery
> org.apache.sqoop.manager.SqlManager::getColumnNamesForProcedure (line 226)
>
> When a connection is in autocommit mode, then a manual commit is not needed
> anyway. When a connection is in read-only mode, then it should still be
> possible to do a rollback in order to close an outstanding transaction.
> I propose to change the mentioned method lines ("connection.commit();" or
> equivalent), to:
> {code:java}
> if (!connection.getAutoCommit()) {
> if (connection.isReadOnly())
> connection.rollback();
> else
> connection.commit();
> }
> {code}
> (or equivalent)
>
> (Overall, I don't know why a commit is done in the above mentioned methods,
> as data should have only been read, if the idea is to just close the
> transaction, why not do a rollback instead just as a safety measure?)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SQOOP-3320) Commit behaviour leads to exceptions on read-only database
[
https://issues.apache.org/jira/browse/SQOOP-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tijmen Ramakers updated SQOOP-3320:
---
Description:
The current Sqoop behaviour is to do a commit after having retrieved the
results of a query. This leads to errors when the database (or the connection)
is in read-only mode.
Example stack traces:
{code:java}
ERROR manager.SqlManager: SQLException closing ResultSet:
org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
read-only
at
org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
at
org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
at
org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
{code}
{code:java}
tool.EvalSqlTool: SQL exception executing statement:
org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
read-only at
org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
org.apache.sqoop.Sqoop.run(Sqoop.java:147)
{code}
When using _sqoop eval_, it is not a major issue since it happens after the
data is already fetched and displayed. When using _sqoop import_ however, the
spawned mapreduce jobs all fail, so this is blocking the whole import.
This commit behaviour exists in several methods, at least the following:
org.apache.sqoop.tool.EvalSqlTool::run (line 78)
org.apache.sqoop.mapreduce.db.DBRecordReader::close (line 169)
org.apache.sqoop.manager.SqlManager::getColumnNamesForRawQuery (line 182)
org.apache.sqoop.manager.SqlManager::getColumnInfoForRawQuery
org.apache.sqoop.manager.SqlManager::getColumnNamesForProcedure (line 226)
When a connection is in autocommit mode, then a manual commit is not needed
anyway. When a connection is in read-only mode, then it should still be
possible to do a rollback in order to close an outstanding transaction.
I propose to change the mentioned method lines ("connection.commit();" or
equivalent), to:
{code:java}
if (!connection.getAutoCommit()) {
if (connection.isReadOnly())
connection.rollback();
else
connection.commit();
}
{code}
(or equivalent)
(Overall, I don't know why a commit is done in the above mentioned methods, as
data should have only been read, if the idea is to just close the transaction,
why not do a rollback instead just as a safety measure?)
was:
The current Sqoop behaviour is to do a commit after having retrieved the
results of a query. This leads to errors when the database (or the connection)
is in read-only mode.
Example stack traces:
{code:java}
ERROR manager.SqlManager: SQLException closing ResultSet:
org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
read-only
at
org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
at
org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
at
org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
{code}
{code:java}
tool.EvalSqlTool: SQL exception executing statement:
org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
read-only at
org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
org.apache.sqoop.Sqoop.run(Sqoop.java:147)
{code}
When using _sqoop eval_, it is not a major issue since it happens after the
data is already fetched and displayed. When using _sqoop import_ however, the
spawned mapreduce jobs all fail, so this is blocking the whole import.
This com
[jira] [Updated] (SQOOP-3320) Commit behaviour leads to exceptions on read-only database
[
https://issues.apache.org/jira/browse/SQOOP-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tijmen Ramakers updated SQOOP-3320:
---
Labels: newbie (was: )
> Commit behaviour leads to exceptions on read-only database
> --
>
> Key: SQOOP-3320
> URL: https://issues.apache.org/jira/browse/SQOOP-3320
> Project: Sqoop
> Issue Type: Bug
> Components: connectors/generic
>Affects Versions: 1.4.7
>Reporter: Tijmen Ramakers
>Priority: Major
> Labels: newbie
>
> The current Sqoop behaviour is to do a commit after having retrieved the
> results of a query. This leads to errors when the database (or the
> connection) is in read-only mode.
> Example stack traces:
> {code:java}
> ERROR manager.SqlManager: SQLException closing ResultSet:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only
> at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
> at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
> {code}
> {code:java}
> tool.EvalSqlTool: SQL exception executing statement:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
> org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
> org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
> org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
> org.apache.sqoop.Sqoop.run(Sqoop.java:147)
>
> {code}
>
> When using _sqoop eval_, it is not a major issue since it happens after the
> data is already fetched and displayed. When using _sqoop import_ however, the
> spawned mapreduce jobs all fail, so this is blocking the whole import.
> This commit behaviour exists in several methods, at least the following:
> org.apache.sqoop.tool.EvalSqlTool::run (line 78)
> org.apache.sqoop.mapreduce.db.DBRecordReader::close (line 169)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForRawQuery (line 182)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForProcedure (line 226)
>
> When a connection is in autocommit mode, then a manual commit is not needed
> anyway. When a connection is in read-only mode, then it should still be
> possible to do a rollback in order to close an outstanding transaction.
> I propose to change the mentioned method lines ("connection.commit();" or
> equivalent), to:
> {code:java}
> if (!connection.getAutoCommit()) {
> if (connection.isReadOnly())
> connection.rollback();
> else
> connection.commit();
> }
> {code}
> (or equivalent)
>
> (Overall, I don't know why a commit is done in the above mentioned methods,
> as data should have only been read, if the idea is to just close the
> transaction, why not do a rollback instead just as a safety measure?)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SQOOP-3320) Commit behaviour leads to exceptions on read-only database
[
https://issues.apache.org/jira/browse/SQOOP-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tijmen Ramakers updated SQOOP-3320:
---
Summary: Commit behaviour leads to exceptions on read-only database (was:
Commit behaviour leads to errors on read-only databases)
> Commit behaviour leads to exceptions on read-only database
> --
>
> Key: SQOOP-3320
> URL: https://issues.apache.org/jira/browse/SQOOP-3320
> Project: Sqoop
> Issue Type: Bug
> Components: connectors/generic
>Affects Versions: 1.4.7
>Reporter: Tijmen Ramakers
>Priority: Major
>
> The current Sqoop behaviour is to do a commit after having retrieved the
> results of a query. This leads to errors when the database (or the
> connection) is in read-only mode.
> Example stack traces:
> {code:java}
> ERROR manager.SqlManager: SQLException closing ResultSet:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only
> at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
> at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
> {code}
> {code:java}
> tool.EvalSqlTool: SQL exception executing statement:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
> org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
> org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
> org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
> org.apache.sqoop.Sqoop.run(Sqoop.java:147)
>
> {code}
>
> When using _sqoop eval_, it is not a major issue since it happens after the
> data is already fetched and displayed. When using _sqoop import_ however, the
> spawned mapreduce jobs all fail, so this is blocking the whole import.
> This commit behaviour exists in several methods, at least the following:
> org.apache.sqoop.tool.EvalSqlTool::run (line 78)
> org.apache.sqoop.mapreduce.db.DBRecordReader::close (line 169)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForRawQuery (line 182)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForProcedure (line 226)
>
> When a connection is in autocommit mode, then a manual commit is not needed
> anyway. When a connection is in read-only mode, then it should still be
> possible to do a rollback in order to close an outstanding transaction.
> I propose to change the mentioned method lines ("connection.commit();" or
> equivalent), to:
> {code:java}
> if (!connection.getAutoCommit()) {
> if (connection.isReadOnly())
> connection.rollback();
> else
> connection.commit();
> }
> {code}
> (or equivalent)
>
> (Overall, I don't know why a commit is done in the above mentioned methods,
> as data should have only been read, if the idea is to just close the
> transaction, why not do a rollback instead just as a safety measure?)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SQOOP-3320) Commit behaviour leads to errors on read-only databases
[
https://issues.apache.org/jira/browse/SQOOP-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tijmen Ramakers updated SQOOP-3320:
---
Summary: Commit behaviour leads to errors on read-only databases (was:
Commit behaviour leeds to errors on read-only databases)
> Commit behaviour leads to errors on read-only databases
> ---
>
> Key: SQOOP-3320
> URL: https://issues.apache.org/jira/browse/SQOOP-3320
> Project: Sqoop
> Issue Type: Bug
> Components: connectors/generic
>Affects Versions: 1.4.7
>Reporter: Tijmen Ramakers
>Priority: Major
>
> The current Sqoop behaviour is to do a commit after having retrieved the
> results of a query. This leads to errors when the database (or the
> connection) is in read-only mode.
> Example stack traces:
> {code:java}
> ERROR manager.SqlManager: SQLException closing ResultSet:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only
> at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
> at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
> at
> org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
> {code}
> {code:java}
> tool.EvalSqlTool: SQL exception executing statement:
> org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
> read-only at
> org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
> at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
> at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
> org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
> org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
> org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
> org.apache.sqoop.Sqoop.run(Sqoop.java:147)
>
> {code}
>
> When using _sqoop eval_, it is not a major issue since it happens after the
> data is already fetched and displayed. When using _sqoop import_ however, the
> spawned mapreduce jobs all fail, so this is blocking the whole import.
> This commit behaviour exists in several methods, at least the following:
> org.apache.sqoop.tool.EvalSqlTool::run (line 78)
> org.apache.sqoop.mapreduce.db.DBRecordReader::close (line 169)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForRawQuery (line 182)
> org.apache.sqoop.manager.SqlManager::getColumnNamesForProcedure (line 226)
>
> When a connection is in autocommit mode, then a manual commit is not needed
> anyway. When a connection is in read-only mode, then it should still be
> possible to do a rollback in order to close an outstanding transaction.
> I propose to change the mentioned method lines ("connection.commit();" or
> equivalent), to:
> {code:java}
> if (!connection.getAutoCommit()) {
> if (connection.isReadOnly())
> connection.rollback();
> else
> connection.commit();
> }
> {code}
> (or equivalent)
>
> (Overall, I don't know why a commit is done in the above mentioned methods,
> as data should have only been read, if the idea is to just close the
> transaction, why not do a rollback instead just as a safety measure?)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SQOOP-3320) Commit behaviour leeds to errors on read-only databases
Tijmen Ramakers created SQOOP-3320:
--
Summary: Commit behaviour leeds to errors on read-only databases
Key: SQOOP-3320
URL: https://issues.apache.org/jira/browse/SQOOP-3320
Project: Sqoop
Issue Type: Bug
Components: connectors/generic
Affects Versions: 1.4.7
Reporter: Tijmen Ramakers
The current Sqoop behaviour is to do a commit after having retrieved the
results of a query. This leads to errors when the database (or the connection)
is in read-only mode.
Example stack traces:
{code:java}
ERROR manager.SqlManager: SQLException closing ResultSet:
org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
read-only
at
org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2819)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2791)
at org.netezza.sql.NzConnection.commit(NzConnection.java:1161)
at
org.apache.sqoop.manager.SqlManager.getColumnNamesForRawQuery(SqlManager.java:182)
at
org.apache.sqoop.manager.SqlManager.getColumnNamesForQuery(SqlManager.java:142)
{code}
{code:java}
tool.EvalSqlTool: SQL exception executing statement:
org.netezza.error.NzSQLException: ERROR: Database 'XXXPRD' is available for
read-only at
org.netezza.internal.QueryExecutor.getNextResult(QueryExecutor.java:280)
at org.netezza.internal.QueryExecutor.execute(QueryExecutor.java:76)
at org.netezza.sql.NzConnection.execute(NzConnection.java:2819) at
org.netezza.sql.NzConnection.execute(NzConnection.java:2791) at
org.netezza.sql.NzConnection.commit(NzConnection.java:1161) at
org.apache.sqoop.tool.EvalSqlTool.run(EvalSqlTool.java:78) at
org.apache.sqoop.Sqoop.run(Sqoop.java:147)
{code}
When using _sqoop eval_, it is not a major issue since it happens after the
data is already fetched and displayed. When using _sqoop import_ however, the
spawned mapreduce jobs all fail, so this is blocking the whole import.
This commit behaviour exists in several methods, at least the following:
org.apache.sqoop.tool.EvalSqlTool::run (line 78)
org.apache.sqoop.mapreduce.db.DBRecordReader::close (line 169)
org.apache.sqoop.manager.SqlManager::getColumnNamesForRawQuery (line 182)
org.apache.sqoop.manager.SqlManager::getColumnNamesForProcedure (line 226)
When a connection is in autocommit mode, then a manual commit is not needed
anyway. When a connection is in read-only mode, then it should still be
possible to do a rollback in order to close an outstanding transaction.
I propose to change the mentioned method lines ("connection.commit();" or
equivalent), to:
{code:java}
if (!connection.getAutoCommit()) {
if (connection.isReadOnly())
connection.rollback();
else
connection.commit();
}
{code}
(or equivalent)
(Overall, I don't know why a commit is done in the above mentioned methods, as
data should have only been read, if the idea is to just close the transaction,
why not do a rollback instead just as a safety measure?)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Review Request 66067: SQOOP-3052: Introduce gradle-based build for Sqoop to make it more developer friendly / open
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66067/#review201990 --- Hey Anna, Thank you for addressing my previous concerns! As a final touch I've tried to compare the contents of the tar.gz we're creating. I've used ``` ant tar ./gradlew tar ``` and ended up with the following differences (right side is gradle): ``` 11a12 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-codegen.bat 12a14 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-create-hive-table.bat 13a16 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-eval.bat 14a18 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-export.bat 15a20 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-help.bat 17a23 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-import-all-tables.bat 18a25,26 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-import-mainframe.bat > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-import.bat 19a28 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-job.bat 20a30 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-list-databases.bat 21a32 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-list-tables.bat 22a34 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-merge.bat 23a36 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-metastore.bat 24a38 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/bin/sqoop-version.bat 72,88d85 < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/ < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/BigDecimalSerializer.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/BlobRef.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/BooleanParser.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/ClobRef.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/DelimiterSet.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/FieldFormatter.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/FieldMapProcessor.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/FieldMappable.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/JdbcWritableBridge.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/LargeObjectLoader.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/LobRef.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/LobSerializer.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/ProcessingException.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/RecordParser.ParseError.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/RecordParser.html < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/class-use/SqoopRecord.html 92d88 < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/docs/api/org/apache/sqoop/lib/package-use.html 163a160 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/lib/avro-ipc-1.8.1.jar 165c162 < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/lib/commons-codec-1.4.jar --- > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/lib/commons-codec-1.9.jar 189a187 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/lib/parquet-hive-bundle-1.6.0.jar 191c189 < sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/lib/slf4j-api-1.6.1.jar --- > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/lib/slf4j-api-1.7.7.jar 342a341 > sqoop-1.5.0-SNAPSHOT.bin__hadoop-2.6.0/src/java/org/apache/sqoop/SqoopVersion.java ``` These fall into the following four categories (in order): 1) Windows executables. There were some conditional parts in build.xml regarding windows. I don't see these in our [latest release](http://www-us.apache.org/dist/sqoop/1.4.7/sqoop-1.4.7.bin__hadoop-2.6.0.tar.gz). Shouldn't we just get rid of all these? 2) Javadoc used to include class usage info (see [here](https://github.com/apache/sqoop/blob/72c5cd717e3fad6d5f5a3a2b3d185ffbacd876cf/build.xml#L1096). I think the 'use' option does the same in gradle (see [here](https://docs.gradle.org/current/javadoc/org/gradle/external/javadoc/StandardJavadocDocletOptions.html#isUse--)). 3) Jar differences under `lib/`. This is what worries me the most. I've had trouble with having (wrong version of) `parquet-hive-bundle` on the classpath. I think we should try to make contents of lib/ the same. One difference I've spotted is that we're not excluding parquet-hive-bundle from kite as we [used to](https://github.com/apache/sqoop/blob/72c5cd717e3fad6d5f5a3a2b3d185ffbacd876cf/ivy.xml#L118). 4) SqoopVersion.java is now included. I think it makes sense to keep it. Any objections? Regards, Daniel
