Page MenuHomePhabricator

Error upgrading MediaWiki from version prior to 1.19 to 1.21: Revision query error during convertUserOptions (missing rev_sha1 column)
Closed, ResolvedPublic


Reported in IRC. When updating from 1.16 to 1.21

I'm confused as to why it's running a Revision query during convertUserOptions being run.

Both the execution of this script, and the addition of rev_sha1 are both 1.19 activities.

Especially if someone can replicate it via testing, I'd probably just suggest moving the rev_sha1/ar_sha1 additions to the top of the 1.19 section so they'd be already run...

...batch conversion of user_options: A database query syntax error has occurred.
The last attempted database query was:
"SELECT rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,page_namespace,page_title,page_id,page_latest,page_is_redirect,page_len,user_name FROM revision INNER JOIN page ON ((page_id = rev_page)) LEFT JOIN user ON ((rev_user != 0) AND (user_id = rev_user)) WHERE page_id = '1547' AND rev_id = '1807' LIMIT 1 "
from within function "Revision::fetchFromConds".
Database returned error "1054: Unknown column 'rev_sha1' in 'field list' ("

Version: 1.21.x
Severity: major



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:31 AM
bzimport set Reference to bz48820.
bzimport added a subscriber: Unknown Object (MLST).

david wrote:

I am able to reproduce this bug while trying to upgrade from REL1_17 to REL1_21. This is the code flow I've been able to track down:

  • MysqlUpdater::getCoreUpdateList() declares that 'doMigrateUserOptions' should be executed before adding the field rev_sha1 into the revision table.
  • ConvertUserOptions::execute() calls User::saveSettings()
  • User::saveSettings() at its very end calls $this->getUserPage()->invalidateCache() and that is where the revision query is joining the party.

I am going to try the suggested fix to move the field addition right before the doMigrateUserOptions step.

david wrote:

Patch that seems to fix the issue

Attaching bug-48820.patch that seems to fix the issue for me.


Hi! Thanks for your patch!

You are welcome to use Developer access

to submit this as a Git branch directly into Gerrit:

Putting your branch in Git makes it easier to review it quickly.
Thanks again! We appreciate your contribution.

  • Bug 49039 has been marked as a duplicate of this bug. ***

hexmode: Got some time to review this Installer two-liner patch?

The patch in this bug looks fine to me. I can test it and apply it if everything else checks out.

I am curious why this has shown up with 1.21 and not earlier releases, though. There have been a few complaints about it.

david wrote:

For the record, I have actually tried a variant of the patch that moves the addition of both rev_sha1 and ar_sha1 prior to executing doMigrateUserOptions. It worked well, too. I thought that keeping these two additions together would be better as they are related - and the resulting code just looks more consistent and readable.

Change 76502 had a related patch set uploaded by Matmarex:
updater: Move rev_sha1 addition before convertUserOptions

There was another report on MediaWiki-General today

However, I'm unable to reproduce the bug.

Change 76502 merged by MarkAHershberger:
updater: Move rev_sha1 addition before convertUserOptions

Patch merged, this will work correctly in MediaWiki 1.22 onward. Now it needs to ba backported to 1.21 and included in a point release.

Change 76627 had a related patch set uploaded by MarkAHershberger:
updater: Move rev_sha1 addition before convertUserOptions

Change 76627 merged by MarkAHershberger:
updater: Move rev_sha1 addition before convertUserOptions

Thanks for the reminder to backport.

Had a reproduction of the problem while upgrading from 1.16 to 1.21. I can verify that the patch fixed it.