Last modified: 2014-09-05 16:41:57 UTC
I updated ee-flow-extra labs instance to wmf/1.23wmf9 (tip `sudo su - vagrant; bash`). php maintenance/update.php crashed MediaWiki 1.23wmf9 Updater Going to run database updates for extrawiki ... Modifying rev_change_type field of table flow_revision ...done. Modifying rc_source field of table recentchanges ...done. Modifying rev_change_type field of table flow_revision ...done. ...site_stats is populated...done. ...Update 'populate rev_len and ar_len' already logged as completed. ...Update 'populate rev_sha1' already logged as completed. ...img_sha1 column of image table already populated. ...protocol-relative URLs in externallinks table already fixed. ...fa_sha1 column of filearchive table already populated. ...Update 'FlowInsertDefaultDefinitions' already logged as completed A database query error has occurred. Query: SELECT workflow_id,workflow_user_text FROM `flow_workflow` WHERE (workflow_id > '\0') AND (workflow_user_ip IS NULL) AND (workflow_user_id = 0) ORDER BY workflow_id LIMIT 200 Function: FlowSetUserIp::updateWorkflow Error: 1054 Unknown column 'workflow_user_ip' in 'where clause' (10.4.1.75) The glitch might be that the ordering is wrong. Flow's db_patches/patch-remove_usernames.sql adds this column, maybe it hasn't run yet. Or it could be ee-flow-extra's wacky DB setup where it's using a different DB. extrawiki only has a blobs table.
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/679, but people from the community are welcome to contribute here and in Gerrit.
The problem was probably extrawiki's DB setup with a separate flowdb on the "cluster." $ mysql flowdb (21:28) root@localhost:[flowdb]> source extensions/Flow/db_patches/patch-remove_usernames.sqlQuery OK, 10 rows affected (0.56 sec) then rerun maintenance/update.php This seems hard to fix unless there's some magic comment that will use $wgFlowExternalStore and $wgFlowDefaultWikiDb to target the right cluster. BTW the FlowSetUserIp script doesn't output anything, there's no indication when it successfully runs
That's a problem with core updater. Maintenance scripts (addPostDatabaseUpdateMaintenance) are usually fine as they fetch the correct DB connection. DB patches are run against core database though. We're fine in production since we always manually do DB updates. Most 3rd party setups will be fine as well, since they'll likely not store data on a separate DB. However, it'd be best if we could figure out a way to let DatabaseUpdater properly apply patches to the correct DB. Probably not easy though: what happens if some patch fails - what do we roll back? etc...
