Change Details

I'm upgrading a wiki farm from 1.30.X to 1.34.X, and finding that a database patch introduced in the 1.33.X releases appears to break the update. This occurs both when upgrading iteratively through the 1.31 and 1.33 releases, and when skipping the intermediate releases and updating from 1.30.X to 1.33.4 or 1.34.2 I've narrowed it down to lines 10-12 in `maintenance/archives/patch-drop-comment-fields.sql` ``` ALTER TABLE /*_*/ipblocks DROP COLUMN ipb_reason, ALTER COLUMN ipb_reason_id DROP DEFAULT; ``` This doesn't appear to be performing a check to see if the table is shared, and is performed even when --doshared is //not// specified. It will run successfully for the first wiki to be upgraded, but all subsequent runs on wikis which share that table will fail with the MySQL error that column ipb_reason does not exist. Checking the ipblocks table local to the wiki reveals the `ipb_reason` column is present, so perhaps this operation is supposed to run against the local table and is being inadvertantly run against the shared table. It occurs whether the --doshared flag is specified or not. I can resolve the error by running the update script once to perform the ALTER operation to the shared table, then commenting out the lines specified above for subsequent runs.

Similar to TT257407 I'm upgrading a wiki farm from 1.30.X to 1.34.X, and finding that a database patch introduced in the 1.33.X releases appears to break the update. This occurs both when upgrading iteratively through the 1.31 and 1.33 releases, and when skipping the intermediate releases and updating from 1.30.X to 1.33.4 or 1.34.2 I've narrowed it down to lines 10-12 in `maintenance/archives/patch-drop-comment-fields.sql` ``` ALTER TABLE /*_*/ipblocks DROP COLUMN ipb_reason, ALTER COLUMN ipb_reason_id DROP DEFAULT; ``` This doesn't appear to be performing a check to see if the table is shared, and is performed even when --doshared is //not// specified. It will run successfully for the first wiki to be upgraded, but all subsequent runs on wikis which share that table will fail with the MySQL error that column `ipb_reason` does not exist. Checking the (unused) `ipblocks` table local to the wiki reveals the `ipb_reason` column is present, so perhaps this operation is supposed to run against the local table and is being inadvertantly run against the shared table. It occurs whether the --doshared flag is specified or not. I can resolve the error by running the update script once to perform the ALTER operation to the shared table, then commenting out the lines specified above for subsequent runs.

Similar to TT257407 I'm upgrading a wiki farm from 1.30.X to 1.34.X, and finding that a database patch introduced in the 1.33.X releases appears to break the update. This occurs both when upgrading iteratively through the 1.31 and 1.33 releases, and when skipping the intermediate releases and updating from 1.30.X to 1.33.4 or 1.34.2 I've narrowed it down to lines 10-12 in `maintenance/archives/patch-drop-comment-fields.sql` ``` ALTER TABLE /*_*/ipblocks DROP COLUMN ipb_reason, ALTER COLUMN ipb_reason_id DROP DEFAULT; ``` This doesn't appear to be performing a check to see if the table is shared, and is performed even when --doshared is //not// specified. It will run successfully for the first wiki to be upgraded, but all subsequent runs on wikis which share that table will fail with the MySQL error that column `ipb_reason` does not exist. Checking the (unused) `ipblocks` table local to the wiki reveals the `ipb_reason` column is present, so perhaps this operation is supposed to run against the local table and is being inadvertantly run against the shared table. It occurs whether the --doshared flag is specified or not. I can resolve the error by running the update script once to perform the ALTER operation to the shared table, then commenting out the lines specified above for subsequent runs.