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. (this will still be the case if the "new table" option is chosen)

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). If page "foo" gets created (page_id 1), then deleted, then recreated (page_id 2), then deleted, then recreated (page_id 3), the delete_page table would have two different rows (dp_id 2 and 3) for the two deleted revision histories. In such case, page creation produces a new page_id.

Otherwise, page creation recovers the entry from archived_page. (What do you mean by "recovers the entry"? Would it then have the same page ID as before?)


 * 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?). (What would be more efficient?)

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.


 * CON: Unique key conflicts with live pages and deleted pages with the same name (Is that a bug or a feature? Why should it be considered a "conflict" rather than something potentially useful? Isn't the conflict resolved by having a different ar_logid for revisions deleted in different page deletion actions?)
 * 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? Is there even any data on that row that needs to be stored, or is this whole "CON" moot?

Bugzilla

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