Last modified: 2014-11-12 03:15:12 UTC
Original bug title: Updater applies patches after fresh install of MW where tables.sql alreay has been patched Verbose description: When patches against the database schema are authored, tables.sql, which is executed upon installation and patch files to be executed when running update.php are submitted. Usually, the updater checks whether a change is applicable (e.g. if a field, table, index, ... exists). However, there are some conditions where the updater cannot know whether a patch already has been applied in tables.sql - changing field lengths, or constraints are examples. Those patches will be applied once, no matter what. (After they were applied, an update key is added to the updatelog table and they aren't applied again.) But the bad may already have happened. Consider the following scenario: Fresh installation, and 2 patches, both increasing the size of one field. First to 255 bytes, second to 1024 bytes. Now run update.php. In fact, the first patch will *decrease* the size to 255 bytes! And Bang! There are currently conflicting patches doing this in core but the foundation for blowing up databases or the updater is settled down. What needs to be changed? All occurrences of “modifyField” in *Updater.php should be replaced by something more reliable or update keys must be inserted by the installer to prevent running patches that are not needed.
For reference, commits inserting modifyField * 0c5301a0d1dfc82088 * 32fde7f35b6dde889f It appears that MySql would throw a warning when reducing field lengths.
See also bug 65283
Change 135756 had a related patch set uploaded by Rillke: Add "chemical" major MIME type to the image tables https://gerrit.wikimedia.org/r/135756
Change 135756 merged by jenkins-bot: Add "chemical" major MIME type to the image tables https://gerrit.wikimedia.org/r/135756
