Change Details

From T270032. This seems to be the most effective and least disruptive solution to me. ``` MariaDB [wikidb]> describe objectcache; +---------+----------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+----------------+------+-----+---------+-------+ | keyname | varbinary(255) | NO | PRI | | | | value | mediumblob | YES | | NULL | | | exptime | datetime | YES | MUL | NULL | | +---------+----------------+------+-----+---------+-------+ 3 rows in set (0.01 sec) ``` [This schema change](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/636049) would change exptime to binary(14). On most installations, this can be done straightforward, because during schema update the table will be truncated and so new values will be filled correctly within the limit of the new type. However, this truncation is configurable, if `--nopurge` option is passed to update script, the table will NOT be truncated, which means old values which are in DATETIME will be cutoff to fit binary(14) (if in sql non-strict mode), and the resulting values will not only be invalid, they could also cause problems to manifest elsewhere, see T270032#6716853. If in sql-strict mode, and the `--nopurge` option is passed, the values will not be truncated but the script will fail with "Data too long for column..." error since in that case the value are not allowed to be truncated. So I think the simple solution to this is to temporarily force truncation of the table even if `--nopurge` option is passed. A message should explain this is for schema change reasons. This would be better than leaving the field to hold invalid values or for the update script to fail midway during update.

From T270032. This seems to be the most effective and least disruptive solution to me. ``` MariaDB [wikidb]> describe objectcache; +---------+----------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+----------------+------+-----+---------+-------+ | keyname | varbinary(255) | NO | PRI | | | | value | mediumblob | YES | | NULL | | | exptime | datetime | YES | MUL | NULL | | +---------+----------------+------+-----+---------+-------+ 3 rows in set (0.01 sec) ``` [This schema change](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/636049) would change exptime to binary(14). On most installations, this is a straightforward change, because during schema update the table will be truncated and so new values will be filled correctly within the limit of the new type. However, this truncation is configurable, if `--nopurge` option is passed to the update script, the table will not be truncated, which means old values which are in DATETIME will be cutoff to fit binary(14) (if in sql non-strict mode), and the resulting values will not only be invalid, they could also cause problems to manifest elsewhere, see T270032#6716853. And if in sql-strict mode, and the `--nopurge` option is passed, the values will not be truncated but I think the script will fail with an error like "Data too long for column..." since in that case the value are not allowed to be truncated. So I think the simple solution to this is to temporarily force truncation of the table even if `--nopurge` option is passed. A message should explain this is for schema change reasons. This would be better than leaving the field to hold invalid values or for the update script to fail midway during update.

From T270032. This seems to be the most effective and least disruptive solution to me. ``` MariaDB [wikidb]> describe objectcache; +---------+----------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+----------------+------+-----+---------+-------+ | keyname | varbinary(255) | NO | PRI | | | | value | mediumblob | YES | | NULL | | | exptime | datetime | YES | MUL | NULL | | +---------+----------------+------+-----+---------+-------+ 3 rows in set (0.01 sec) ``` [This schema change](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/636049) would change exptime to binary(14). On most installations, this can be doneis a straightforward change, because during schema update the table will be truncated and so new values will be filled correctly within the limit of the new type. However, this truncation is configurable, if `--nopurge` option is passed to the update script, the table will NOTnot be truncated, which means old values which are in DATETIME will be cutoff to fit binary(14) (if in sql non-strict mode), and the resulting values will not only be invalid, they could also cause problems to manifest elsewhere, see T270032#6716853. IAnd if in sql-strict mode, and the `--nopurge` option is passed, the values will not be truncated but I think the script will fail with an error like "Data too long for column..." error since in that case the value are not allowed to be truncated. So I think the simple solution to this is to temporarily force truncation of the table even if `--nopurge` option is passed. A message should explain this is for schema change reasons. This would be better than leaving the field to hold invalid values or for the update script to fail midway during update.