JonasGao opened a new issue #11251:
URL: https://github.com/apache/shardingsphere/issues/11251
## Question
When I migrated the legacy code, I did not pay attention to the table
structure is not suitable for sharding.
After completing the Sharding configuration. I test my code. It is an insert
operation. I found that it did not report an error, but returned the number of
affected rows "-1". I was confused at the time. After many attempts, I amended
the table structure. Normally, SQLException will be thrown in this case.
Afterwards, I briefly read the source code.
So, why does JDBCExecutorCallback not throw SQLException
Let's give a chestnut 🙋♂️
```
CREATE TABLE ht_supply_price_sku_adjust
(
id INT AUTO_INCREMENT PRIMARY KEY,
sku VARCHAR(100) NOT NULL
)
```
And use default key generate strategy. Default key is of type LONG. INT will
fail.
Now when you insert into some table like `ht_supply_price_sku_adjust_01`. it
will return -1
The source code is there
```
public abstract class JDBCExecutorCallback<T> implements
ExecutorCallback<JDBCExecutionUnit, T> {
private T execute(JDBCExecutionUnit jdbcExecutionUnit, boolean
isTrunkThread, Map<String, Object> dataMap) throws SQLException {
...
try {
...
} catch (SQLException var8) {
// why not throw the var8
if (!isTrunkThread) {
return null;
} else {
Optional<T> saneResult =
this.getSaneResult(this.sqlStatement);
if (saneResult.isPresent()) {
return saneResult.get();
} else {
sqlExecutionHook.finishFailure(var8);
SQLExecutorExceptionHandler.handleException(var8);
return null;
}
}
}
}
}
```
--
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]
