On Mon, 6 Mar 2017 at 16:52 MZMcBride z@mzmcbride.com wrote:
For a "regular" MediaWiki installation, will making these changes be a matter of simply updating MediaWiki's application code and running maintenance/update.php?
Yes.
For Wikimedia wikis, as far as I know update.php is never run.
Correct; it'd take down the cluster.
Are you planning to write separate maintenance scripts for this?
Yes.
As is "normal" with schema changes, in Wikimedia production this will be done manually by the DBAs https://wikitech.wikimedia.org/wiki/Schema_changes. It is a careful, very slow process that manages the otherwise-impossible. It will take months of their time, is seriously laborious, and blocks any other such changes. A recent user-facing example is T69223 https://phabricator.wikimedia.org/T69223, which was required to support translation from non-English languages on multi-content wikis. This is why the DBAs' views are so important. :-)
Once the schema change is done, we may/will back-fill old rows to populate the new schema, using maintenance scripts for each wiki. However, given that the table we're talking about is revision with over three quarters of a billion rows on enwiki alone, that will be exceptionally slow-running.
Once all *that* is done, we could do a further schema change to drop the old bits of the schema that are no longer used (again, slow), and then drop the backwards-compatible database code from MediaWiki. But that's optional.
Regarding scope, this is a lot of changes. How are all of these changes
intended to be divided? Are we able to move forward with some changes (e.g., adding a comment table) without moving forward with other changes (e.g., adding a user_entry table)?
Yes, but given that this round will take years to complete, deciding to delay some of the things means upsetting a lot of plans.
J.