Talk:Requests for comment/Page deletion

To clarify, do these proposals call for the archive table to be removed and for deleted revisions to be kept in the revision table? Leucosticte (talk) 18:02, 23 October 2012 (UTC)

Conflicts
"CON: unique key conflicts with live pages and deleted pages with the same name" Is that a bug or a feature? It seems to me that we want to keep the live and deleted pages with the same name under the same unique key, unless there's a reason to split them up. I propose that there will be a field, e.g. a modified log_params or the proposed rev_logid, that will make it possible to easily separate them again, e.g. for deletions/undeletions of a group of edits. What specific issues/difficulties are people concerned about this "con" causing? Leucosticte (talk) 06:41, 19 October 2013 (UTC)

New table more secure by default
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. Aaron 20:23, 27 October 2011 (UTC)
 * How big of an issue is it? Don't these same issues arise with, say, the methods that allow raw revisions to be retrieved instead of seeing whether the user is supposed to have access to them? It doesn't seem like too much to ask that the extension writers select only the data that they're supposed to select given security concerns, and that system administrators not install extensions that have security flaws. Leucosticte (talk) 07:58, 19 October 2013 (UTC)

Page data
CON: What happens to the old page entry? Moved to another table? Aaron 20:23, 27 October 2011 (UTC)
 * What data are you trying to save from the page table? Presently, the only page table fields stored in the archive table are ar_namespace, ar_title, and Manual:Archive_table. With the new field scheme, ar_page_id would be obsolete (rev_page would suffice because the page ID wouldn't change across deletions and revisions). Nor do the namespace or title change. So it seems to me that there is nothing more to store.


 * Thus, the page row can just hold the new page's data or, if everything is still deleted, the old page's data. But if some data does need to be saved, perhaps it could be included in the serialized data in Manual:Logging table? Or, if that's unsuitable, we could add another log table field.


 * The proposed rev_logid would link to the log_id of the logging table row containing that metadata. I'm not sure what need there is for a whole new table; what would you use it for, that a field would be unsuitable for? Are there a lot of queries we anticipate running that would be more efficient if there were a new table instead of just a serialized field? Admittedly, it might be cheaper to query a relatively small table of deleted pages (what would we call it? deleted_page?) than the logging table, although I don't think it would be much cheaper. Leucosticte (talk) 07:58, 19 October 2013 (UTC)

Delete revisions on page deletion?
With either approach, we could mark as deleted all revisions or rely on the page change to not allow them to be accessed. The later favours fast deletion and undeletion. The first aims for consistency. However, deleting one revision, then deleting the full page and undeleting should have kept that revision gone...
 * This would be a bad idea: if some revisions of the page were deleted (e.g. for legal reasons), these would get inadvertently get restored when deleting and restoring the page. If we leave the revisions as they were, deleting and restoring the page will keep the deleted revisions intact. Duesentrieb ⇌ 08:36, 8 August 2013 (UTC)
 * I disagree; we could add another field, rv_logid, for the log_id of the deletion event. Then upon restoring the page, only the revisions pertaining to the pertinent deletion event would be restored. So, suppose you revision delete (log_id 1). Then you delete the whole page (log_id 2). Then you undelete the page. You only restore the revisions that have rv_logid 2, and leave the rv_logid 1 revisions deleted. Leucosticte (talk) 05:23, 7 October 2013 (UTC)

Semi-deletion, aka pure wiki deletion
It seems to me that the field option would work pretty well for semi-deletion, aka pure wiki deletion. Semi-deletion assumes that the average user will still want to routinely look at revisions of articles that have been removed from the AllPages listing for being not yet ready for prime time, e.g. because the information hasn't been verified or whatever. Collaboration can continue on these pages, e.g. if the user improves the article to the point that it is now ready to be undeleted. But he has to be able to see the old revisions in order to build upon the work that was done earlier rather than starting from scratch. Leucosticte (talk) 09:07, 19 October 2013 (UTC)