By mondrake on
Change record status:
Published (View all published change records)
Project:
Introduced in branch:
11.5.x
Introduced in version:
11.5.0
Issue links:
Description:
TRUNCATE's ::execute() method is currently returning an integer value, but that is fragile:
/**
* Executes the TRUNCATE query.
*
* In most cases, TRUNCATE is not a transaction safe statement as it is a DDL
* statement which results in an implicit COMMIT. When we are in a
* transaction, fallback to the slower, but transactional, DELETE.
* PostgreSQL also locks the entire table for a TRUNCATE strongly reducing
* the concurrency with other transactions.
*
* @return int|null
* Return value is dependent on whether the executed SQL statement is a
* TRUNCATE or a DELETE. TRUNCATE is DDL and no information on affected
* rows is available. DELETE is DML and will return the number of affected
* rows. In general, do not rely on the value returned by this method in
* calling code.
*
* @see https://learnsql.com/blog/difference-between-truncate-delete-and-drop-table-in-sql
*/
public function execute() { ...
The Truncate class has now been changed to implement a new QueryExecutionVoidInterface that is ensuring ::execute not to return any value.
/**
* General class for an abstracted TRUNCATE operation.
*/
class Truncate extends Query implements QueryExecutionVoidInterface {
...
/**
* Executes the TRUNCATE query.
*
* In most cases, TRUNCATE is not a transaction safe statement as it is a DDL
* statement which results in an implicit COMMIT. When we are in a
* transaction, fallback to the slower, but transactional, DELETE.
* PostgreSQL also locks the entire table for a TRUNCATE strongly reducing
* the concurrency with other transactions.
*
* @see https://learnsql.com/blog/difference-between-truncate-delete-and-drop-table-in-sql
*/
public function execute(): void { ...
Impacts:
Module developers