Last modified: 2010-05-15 15:38:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2883 - Search index not being updated after upgrade from 1.4
Search index not being updated after upgrade from 1.4
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
1.5.x
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-17 03:04 UTC by Steven Hilton
Modified: 2010-05-15 15:38 UTC (History)
0 users

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


Attachments

Description Steven Hilton 2005-07-17 03:04:15 UTC
I was running 1.4 and a few days ago I upgraded to 1.5beta3.  I ran the two
commandline php upgrade scripts in order --  upgrade1_5.php update.php.

The upgrade seemed to have been completely transparent and successful. Then late
friday afternoon (it's always a late friday afternoon, isn't it?), people began
to notice that searching wasn't working.

I'm not that familiar with mediawiki's internals yet, but I think I this may
provide some relevant info:

New articles created since the upgrade are not getting into the index. I even
dropped and rebuilt in search index with rebuildtextindex.php hoping that would
work, but I still get the same results -- only content created while still
running the 1.4 version is showing up in the search results even after a rebuild.

I *think*, but am not really not sure, that it has something to with how stuff
gets into the index. The index update is triggered by data in the
'recentchanges' table? The updateSearchIndex.php script seems to select against
the recentchanges table to find out what to put in the search index. 

In trying to track in down further, I found that running the
'rebuildrecentchanges.php' script dies with this error:

 php rebuildrecentchanges.php
Loading from CUR table...
Loading from OLD table...
A database error has occurred
Query: INSERT INTO `recentchanges`
(rc_timestamp,rc_cur_time,rc_user,rc_user_text,rc_namespace,rc_title,rc_comment,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type)
SELECT
old_timestamp,cur_timestamp,old_user,old_user_text,old_namespace,old_title,old_comment,old_minor_edit,0,0,cur_id,old_id,0,0
FROM `old`,`cur` WHERE old_namespace=cur_namespace AND old_title=cur_title ORDER
BY old_timestamp DESC LIMIT 5000
Function:
Error: 1146 Table 'midev_wiki_db.old' doesn't exist

And sure enough, the 'old' table does not exist in my schema. Further, when I
ran the script, *I lost all of the recent changes data made since the upgrade.*
 The content and history of individual articles was not lost, and new edits do
still go into the recentchanges table.  But I'm afraid I just lost several days
of recent changes data by running a maintenance script.

I will continue to investigate as time allows.
Comment 1 Steven Hilton 2005-07-18 13:30:24 UTC
I retract this bug. My comments are a red herring. My problem dealt with mysql
full index search.

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


Navigation
Links