On Mon, 6 Mar 2017 at 16:52 MZMcBride <z(a)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.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester at
wikimedia.org
<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> |
@jdforrester