Page MenuHomePhabricator

Updater for 'redirect' table tries to read from 'pagelinks' before that table is created in upgrade from 1.2.6
Closed, ResolvedPublic

Description

A user trying to upgrade from 1.2.6 reported failure of the 'redirect' table
updater script, whose second part is reading data out of 'pagelinks' and 'page'.

Since the table and field updaters are run in a batch before bigger updaters,
this seems to be running out of order; the structure migration hasn't happened
yet so there's no tables to read from.

This may break upgrades from other pre-1.4 releases as well.


Version: 1.9.x
Severity: normal

Details

Reference
bz8638

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:29 PM
bzimport set Reference to bz8638.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

(In reply to comment #0)

Since the table and field updaters are run in a batch before bigger updaters,
this seems to be running out of order; the structure migration hasn't happened
yet so there's no tables to read from.

Is there any reason we couldn't split the batches into those which depend on the
1.5 schema, and those which should be done beforehand?

My recommendation would be to have a completely ordered set of updates; right
now there's a couple of different orderings:

  1. everything in $wgRenamedTables
  2. everything in $wgNewTables
  3. everything in $wgNewFields
  4. the rest of the calls from do_all_updates() in the order they appear

Those handy-dandy lists are easier than writing functions one by one for every
minor update, but it can lead to ordering problems like here.

A single list which can combine table renames, new tables, new fields, and
function calls to more complicated things might be wise. This could either be
use of handier functions added to do_all_updates() to replace the arrays, or an
array which can include all those types of data sets.

The 1.5 restructuring doesn't have to be treated specially in that case; it's
just one of the steps.

Fixed in r19373 on trunk and r19374 on 1.9 branch; will be in 1.9.1.

A fuller cleanup might still be cute though :D