[CONJ-384] Add option permit having "affected" or "found" rows Created: 2016-11-04 Updated: 2019-06-10 Resolved: 2018-07-19 |
|
| Status: | Closed |
| Project: | MariaDB Connector/J |
| Component/s: | Other |
| Affects Version/s: | 1.5.5 |
| Fix Version/s: | 2.2.6, 1.8.0 |
| Type: | Task | Priority: | Minor |
| Reporter: | sjachym | Assignee: | Diego Dupin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Like said in old comment, add "useAffectedRows" property in url connection. Like MySQL connector : useAffectedRows Don't set the CLIENT_FOUND_ROWS flag when connecting to the server (not JDBC-compliant, will break most applications that rely on "found" rows vs. "affected rows" for DML statements), but does cause "correct" update counts from "INSERT ... ON DUPLICATE KEY UPDATE" statements to be returned by the server. Default: false Since version: 5.1.7 |
| Comments |
| Comment by Diego Dupin [ 2018-02-01 ] |
|
A note for writing documentation, this option is not compatible with the option "rewriteBatchedStatements" : if the 2 options are set, executeBatch() will not return the number of affected rows as expected. |
| Comment by Pavel Cibulka [ 2019-04-18 ] |
|
Is there anything than can be done? Mysql connector/j have similar problem with rewriteBatchedStatements and useAffectedRows. They have been able to make it work at last for situation, when no row is changed. This would be enough. See: https://bugs.mysql.com/bug.php?id=68562 From mysql bug: "When rewriteBatchedStatements=true and useAffectedRows=true were set, executeBatch() did not return the number of affected rows as expected, but always returned a “1,” even if no rows were affected (for example, when an ON DUPLICATE KEY UPDATE clause was applicable but the data needed no changes). The “1” was actually a hardwired value, a workaround for a known issue on the server side, which does not return the number of affected rows in such cases. This fix makes Connector/J just return the value given by the server anyway, which means the returned number of affected rows is reliable now if Connector/J returns a “0” [no rows affected]; non-zero values returned should not be trusted though." |
| Comment by Pavel Cibulka [ 2019-06-10 ] |
|
I've made improvement patch for case when no changes happened. |