sandynz commented on code in PR #20668:
URL: https://github.com/apache/shardingsphere/pull/20668#discussion_r959149700
##########
shardingsphere-kernel/shardingsphere-data-pipeline/shardingsphere-data-pipeline-core/src/main/java/org/apache/shardingsphere/data/pipeline/scenario/migration/MigrationDataConsistencyChecker.java:
##########
@@ -119,16 +123,16 @@ private Map<String, DataConsistencyCountCheckResult>
checkCount() {
}
}
- private DataConsistencyCountCheckResult checkCount(final String table,
final PipelineDataSourceWrapper sourceDataSource, final
PipelineDataSourceWrapper targetDataSource,
+ private DataConsistencyCountCheckResult checkCount(final
PipelineDataSourceWrapper sourceDataSource, final PipelineDataSourceWrapper
targetDataSource,
final
ThreadPoolExecutor executor) {
try {
- Future<Long> sourceFuture = executor.submit(() ->
count(sourceDataSource, table, sourceDataSource.getDatabaseType()));
- Future<Long> targetFuture = executor.submit(() ->
count(targetDataSource, table, targetDataSource.getDatabaseType()));
+ Future<Long> sourceFuture = executor.submit(() ->
count(sourceDataSource, sourceTableName, sourceDataSource.getDatabaseType()));
+ Future<Long> targetFuture = executor.submit(() ->
count(targetDataSource, targetTableName, targetDataSource.getDatabaseType()));
long sourceCount = sourceFuture.get();
long targetCount = targetFuture.get();
return new DataConsistencyCountCheckResult(sourceCount,
targetCount);
} catch (final InterruptedException | ExecutionException ex) {
- throw new
PipelineDataConsistencyCheckFailedException(String.format("Count check failed
for table '%s'", table), ex);
+ throw new
PipelineDataConsistencyCheckFailedException(String.format("Count check failed
for table '%s'", sourceDataSource), ex);
}
Review Comment:
1, Looks `sourceDataSource` should be `sourceTableName`
2, Maybe `targetTableName` should be added too. Is it necessary to use 2
`try ... catch`?
##########
shardingsphere-test/shardingsphere-integration-test/shardingsphere-integration-test-scaling/src/test/resources/env/scenario/general/postgresql.xml:
##########
@@ -56,19 +56,11 @@
<full-insert-order>
INSERT INTO
-
test.t_order(id,order_id,user_id,status,t_int2,t_numeric,t_bool,t_char,t_varchar,t_float,t_double,t_timestmap,t_timestamptz)
+
test.t_order_copy(id,order_id,user_id,status,t_int2,t_numeric,t_bool,t_char,t_varchar,t_float,t_double,t_timestmap,t_timestamptz)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?)
</full-insert-order>
<full-insert-order-item>
INSERT INTO test.t_order_item(item_id,order_id,user_id,status)
VALUES(?,?,?,?)
</full-insert-order-item>
-
- <update-table-order-status>
- UPDATE test.t_order SET status= 'unlock'
- </update-table-order-status>
-
- <create-index-status>
- CREATE INDEX "idx_user_status" ON test.t_order ( status )
- </create-index-status>
Review Comment:
Is `CREATE INDEX` not need to test any more?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
