Page MenuHomePhabricator

rebuildrecentchanges zaps all deletions due to looking in wrong table
Closed, ResolvedPublic

Description

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.)


Version: 1.16.x
Severity: major

Details

Reference
bz18291

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:32 PM
bzimport set Reference to bz18291.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 5984
Don't forget newly created users when rebuilding

Patch to get 'create'd new users too.

Better would be a NOT IN() exclusion list.

Attached:

(In reply to comment #2)

Created an attachment (id=5984) [details]
Don't forget newly created users when rebuilding

Done in r49136

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?

(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.

overlordq wrote:

This bug was resolved, marking back as such.

Jdforrester-WMF subscribed.

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.