#1266572: Workaround in UpdateQuery_sqlite for affected rows count causes certain updates to be suppressed In Drupal 8, update queries always return the number of rows matched by the query, which includes rows that didn't have to be updated because they're values wouldn't have changed. Remaining tasksĭecide on a backport to Drupal 7 ensuring consistency between all database systems. This flag ensures consistency of MySQL's behaviour with PostgreSQL and SQLite, without relying on query rewrites or other workarounds.

Proposed resolutionįor Drupal 8, we decided to use the PDO::MYSQL_CLIENT_FOUND_ROWS flag which was introduced in 5.3 with PHP #44135, but is only consistently available only from PHP 5.3.5 with PHP #53425, which we're anyway requiring in D8. Finally the affected rows are only checked in our MySQL-based tests, but not otherwise used in core. With MySQL being our primary database platform, in D7 we implemented a workaround for SQLite but missed PostgreSQL and InnoDB 5.1.0 - 5.1.24. This has been reverted with MySQL #29157, so InnoDB again matches MyISAM starting with MySQL versions 5.1.24 and 5.5.

In line with the ANSI SQL standard, both PostgreSQL and SQLite define 'affected rows' as all rows matched by the query.įor MySQL, the definition however depends: While MyISAM always returned the number of rows that really had to be changed, on InnoDB it used to be the same, but starting with MySQL 5.1 this changed to returning all rows matched by the query. It turned out that PDO's number of affected rows was highly dependent on the database engine and therefore not reliable: When updating a database record in D7, according to the documentation UpdateQuery->execute() returned 'the number of rows affected by the update', relying on PDO's return value.

Pdo update query affected rows