BATCH
BATCH = 500
How many rows are inserted per statement.
Builds the new contents in a shadow table and renames it into place.
The original stays readable and complete until the instant of the swap, so a site can restore one table without going into maintenance mode. That is the whole reason this exists next to the truncate strategy, which is simpler and works everywhere.
It is only atomic where the driver can rename two tables in one statement. MySQL's
RENAME TABLE a TO a_old, b TO a is one operation with no window in which the name is unbound.
PostgreSQL's ALTER TABLE ... RENAME is per-table, but two of them inside a transaction commit
together, which gives the same guarantee. SQLite can rename a table and cannot do either
atomically, so a reader can find the name missing between the two statements.
On SQLite it refuses rather than degrading. A strategy that quietly fell back to truncating would give an operator the swap's promise and the truncate's behaviour, and the one moment that matters is the moment they were relying on the promise.
restore(\Drupal\Core\Database\Connection $database, string $table, array $rows, array $columns) : int
Replaces a table's contents.
| \Drupal\Core\Database\Connection | $database | The connection. |
| string | $table | The table to replace. |
| array | $rows | The rows to leave in it. An empty list empties the table, which is a legitimate restore target and is why this does not treat it as a mistake. |
| array | $columns | The columns to write, in order. Given explicitly so a row carrying a column the table no longer has is refused rather than silently dropped. |
How many rows the table now holds.