Someone on irc had a very screwed up DB, and he reported that the updater gave a...

when trying to update (appearently did not have a recentchanges table, and one of the db
functions returned false, which the updater did not expect). Add check for that since I figure
an exception is much better than a fatal error.

The relavent error this potentially stops is:
Fatal error: Call to a member function isMultipleKey() on a non-object in /../includes/installer/MysqlUpdater.php on line 249"

Not sure if the updater should do something better than an exception, but it seems like
a much better situation than the fatal.

In practise, I think it is rare that this situation would arise.

diff --git a/RELEASE-NOTES-1.19 b/RELEASE-NOTES-1.19
index 97b1d34..e8d54df 100644 (file)
--- a/RELEASE-NOTES-1.19
+++ b/RELEASE-NOTES-1.19
@@ -113,6 +113,8 @@ production.
 * (bug 29492) Long-running steps in the installer (such as Upgrade and Install)
   can sometimes timeout
 * (bug 29507) Change 'image link' to 'file link' in Special:Whatlinkshere
+* If the db is really screwed up, and doesn't have a recentchanges table,
+  make the updater throw an exception instead of a fatal.
 
 === API changes in 1.19 ===
 * BREAKING CHANGE: action=watch now requires POST and token.

diff --git a/includes/installer/MysqlUpdater.php b/includes/installer/MysqlUpdater.php
index f4bc3ef..b4e9ac5 100644 (file)
--- a/includes/installer/MysqlUpdater.php
+++ b/includes/installer/MysqlUpdater.php
@@ -254,6 +254,9 @@ class MysqlUpdater extends DatabaseUpdater {
         */
        protected function doIndexUpdate() {
                $meta = $this->db->fieldInfo( 'recentchanges', 'rc_timestamp' );
+               if ( $meta === false ) {
+                       throw new MWException( 'Missing rc_timestamp field of recentchanges table. Should not happen.' );
+               }
                if ( $meta->isMultipleKey() ) {
                        $this->output( "...indexes seem up to 20031107 standards\n" );
                        return;