Last modified: 2010-05-15 15:48:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T10638, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8638 - Updater for 'redirect' table tries to read from 'pagelinks' before that table is created in upgrade from 1.2.6
Updater for 'redirect' table tries to read from 'pagelinks' before that table...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.9.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-15 03:41 UTC by Brion Vibber
Modified: 2010-05-15 15:48 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2007-01-15 03:41:30 UTC
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.
Comment 1 Rob Church 2007-01-15 05:01:24 UTC
(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?
Comment 2 Brion Vibber 2007-01-15 05:30:03 UTC
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.
Comment 3 Brion Vibber 2007-01-17 10:09:34 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links