6.3.2

• manage.py migrate_uuids --execute refuses to start when the run needs disk space and the server is not provably this host (a socket or loopback connection to a server that reports this host's name): that space cannot be measured from here, and it only warned before. A server in a container reached through loopback, another address of this machine or a hostname alias count as another host. Check the server's free space by hand and run again with --skip-space-check. Dry runs still only warn.

• manage.py migrate_uuids exits with status 1 when a statement fails (it printed "CRITICAL ERROR" and exited 0), when --disable-copy-bulk cannot restore innodb_alter_copy_bulk, and on a database that is not MySQL/MariaDB. A failed run prints the statement that failed and the state of every UUID column (not converted, half converted, converted); running the command again resumes it. SET FOREIGN_KEY_CHECKS=1 now runs also after a failed statement, so the session is not left with foreign key checks off.

• manage.py migrate_uuids reads the values, not only the column type. A column already at the target length that still holds values in the old format (a run cut after its ALTER, which the next run reported as compliant) is planned again, UPDATE only. Values that are neither 32 hex characters nor a dashed UUID are listed, and --execute refuses to start while a column it would convert holds any: the conversion would leave them unreadable or truncate them. The UPDATEs match the format (REGEXP) instead of the length, so a 32-character value that is not hex is no longer turned into 36 characters of garbage. A native uuid column (MariaDB >= 10.7) counts as compliant for --target 36 instead of being planned as "None -> 36", and a table mapped by two models is planned once. The dry run says which columns block --execute. Reading the values costs one COUNT per column, in dry runs too: about 2.6 s per 3 million rows with an index on the column, a full table scan without one.

• manage.py migrate_uuids --execute adds STRICT_ALL_TABLES to the session sql_mode for the run and restores it afterwards, so a value that does not fit stops the run instead of being truncated on a server configured without strict mode.

• manage.py migrate_uuids estimates the disk per directory of the server and no longer blesses runs that fail: tmpdir needs 2.5 times the largest rebuilt table with innodb_alter_copy_bulk ON (1 times before; merge files were measured at up to 2.46 times, so the margin is thin), and innodb_tmpdir is no longer read, since the merge files go to tmpdir anyway; every directory of a colon-separated tmpdir is checked; with a binary log in ROW format, the UPDATE phase needs 2.5 times the updated tables in the binary log directory and 2.5 times the largest one in tmpdir (transaction cache), which was not counted (the binary log of a ROW_FORMAT=COMPRESSED table was measured at 3.34 times: there the estimate is short, and a full disk stops the run with status 1); directories on the same filesystem add their requirements up. Free space is measured only when the connection is a socket or loopback one and the server's @@hostname is this host's name: a path that merely exists on the client is no proof, and was measured on the client's filesystem. It reminds that the sizes are InnoDB estimates, far too low right after an import until ANALYZE TABLE runs.

• New system check codenerix.E008: OTP_VALID_WINDOW that is not a non-negative integer. A string (for instance from an environment variable) raised TypeError at login and a negative value refused every code; OTPAuth now falls back to 0, the current step only. It is an Error, so check, migrate and runserver stop until the setting is fixed, and True, accepted as 1 until now, is rejected.