Last modified: 2012-08-04 20:49:01 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 18291 - rebuildrecentchanges zaps all deletions due to looking in wrong table
rebuildrecentchanges zaps all deletions due to looking in wrong table
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.16.x
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: postgres 13453
  Show dependency treegraph
 
Reported: 2009-03-31 23:35 UTC by Dan Jacobson
Modified: 2012-08-04 20:49 UTC (History)
2 users (show)

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


Attachments
Don't forget newly created users when rebuilding (550 bytes, patch)
2009-04-01 23:30 UTC, Dan Jacobson
Details

Description Dan Jacobson 2009-03-31 23:35:06 UTC
Delete a page, check RecentChanges for the entry, there you see it.
Now run rebuildrecentchanges.php. Check RecentChanges... it is gone!

The problem is that rebuildrecentchanges.inc assumes that
	'log_namespace=page_namespace',
	'log_title=page_title',
can also be applied to deletions.

But deleted pages will not have an entry in the page table! Don't look
for them in the page table, instead please separately look for them in
the archive table!

Users are angry: "Why is the administrator deleting articles behind
our backs? If there is a problem with an article I wrote, then go
ahead and delete it, but at least don't try to cover up the evidence
that you did!"

The administrator replies: "The deletions are right there in
RecentChanges, along with my carefully worded reasons ... until one
day I ran rebuildrecentchanges.php!"

(Feel free to recategorized this bug under "Maintenance scripts".
I'm just noting that it ruins what is seen on the special page RecentChanges.)
Comment 1 Roan Kattouw 2009-04-01 07:25:57 UTC
Fixed in r49112
Comment 2 Dan Jacobson 2009-04-01 23:30:25 UTC
Created attachment 5984 [details]
Don't forget newly created users when rebuilding

Patch to get 'create'd new users too.

Better would be a NOT IN() exclusion list.
Comment 3 Roan Kattouw 2009-04-02 10:38:20 UTC
(In reply to comment #2)
> Created an attachment (id=5984) [details]
> Don't forget newly created users when rebuilding
> 
Done in r49136
Comment 4 Dan Jacobson 2009-06-28 01:10:33 UTC
Bug 13453 points to MySQLisms in r49112.
I.e., Catrope: you may have used a mysqlism.
Perhaps all such mysqlisms could be grepped for and rooted out of all code?
Comment 5 Roan Kattouw 2009-06-30 10:49:21 UTC
(In reply to comment #4)
> Bug 13453 points to MySQLisms in r49112.
> I.e., Catrope: you may have used a mysqlism.
> Perhaps all such mysqlisms could be grepped for and rooted out of all code?
> 

It wasn't a MySQLism, since COALESCE() exists in PostgreSQL as well. The problem was that PostgreSQL seems to somehow require that rc_cur_id be a valid page ID or NULL, while we use 0 for this kind of thing pretty much everywhere else. IMO this foreign key should either be reconfigured to allow 0 or be removed.
Comment 6 OverlordQ 2009-10-28 18:21:47 UTC
This bug was resolved, marking back as such.

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


Navigation
Links