Last modified: 2014-05-08 09:08:41 UTC
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' (10.0.0.48)"
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.
Created attachment 12428 [details] 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 https://www.mediawiki.org/wiki/Developer_access to submit this as a Git branch directly into Gerrit: https://www.mediawiki.org/wiki/Git/Tutorial 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.
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 https://gerrit.wikimedia.org/r/76502
There was another report on #mediawiki today http://pastebin.com/YFschha8 However, I'm unable to reproduce the bug.
Change 76502 merged by MarkAHershberger: updater: Move rev_sha1 addition before convertUserOptions https://gerrit.wikimedia.org/r/76502
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 https://gerrit.wikimedia.org/r/76627
Change 76627 merged by MarkAHershberger: updater: Move rev_sha1 addition before convertUserOptions https://gerrit.wikimedia.org/r/76627
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.
