Requests for comment/Page deletion

This page serves as ground for discussion on the best way to integrate RevDelete with normal page deletion. Wikitech thread:

Particularly, moving page deletion to a RevDelete mechanism would solve:
 * 21279 RevDelete + Normal deletion break log links.
 * 18104 Deleted revisions should be identified by id, not timestamp.
 * Easy comparison between deleted revisions and existing ones.
 * It is really expensive to delete pages with lots of revisions.
 * Page protection can be kept on delete + undelete cycles.
 * Groups of revisions that are deleted are merged with all other deleted revisions for that page making them indistinguishable from each other.
 * page_id changes when a page is deleted and then restored.

archived_page table
Use a table similar to page which holds page content when it is deleted.

Deleting a page is moving the page entry to a new entry in the archived_page table.

We could have different deleted pages: groups of revisions which once existed at the same history. So revisions are no longer mixed. Each deleted page has a different page_id (although they share namespace and title). In such case, page creation produces a new page_id.

Otherwise, page creation recovers the entry from archived_page.


 * PRO: page JOIN already done in core. Also, most places want to join to get the page for other reasons anyway, so this has some "secure by default" nature to it.

page_deleted field
Add a page_deleted field to the table page. The page is marked on the page_deleted bitfield as no longer existing. Another option would be to define that page doesn't exist if it has no visible [latest] edit (page_latest=0?).

Possibly add a rev_logid field to hold the log_id of the deletion event. At any rate, log_params or another logging table field should probably hold, in serialized form, all the rev_ids of revisions deleted and restored in a particular log action so that these actions can be easily reversed.

Page creation reuses the same page entry if it exists.


 * PRO: Could make it significantly easier to implement semi-deletion.
 * CON: Unique key conflicts with live pages and deleted pages with the same name
 * CON: We will need to add "rev_page = page_id AND page_deleted = 0" checks in revision queries.
 * CON: What happens to the old page entry? Moved to another table? Or stored in serialized form in a field?

Bugzilla

 * 55398 &mdash; Move page deletion to a RevDelete mechanism; kill archive table (fire optional)