Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
1.5.5
-
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
Attachments
Activity
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:
[22 May 2014 17:20] Daniel So
Edited the entry in the 5.1.27 changelog to clarify on what had happened with this old fix:
"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."
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.