https://bugzilla.wikimedia.org/show_bug.cgi?id=55398
--- Comment #8 from Nathan Larson <[email protected]> --- Aaron: Would you consider it a bug or a feature that: (1) When a page is deleted and then restored, it gets a new page ID; (2) When a page is deleted and then recreated (i.e. a new page with the same page title is created), the new page has a new page ID (rather than the same page ID as the deleted page); and (3) When a page is deleted, and then a new page is created with the same page title, the two revision histories have different page IDs (in rev_page and ar_page_id)? The "new field" proposal would change all three of the above, for good or bad. Any page recreations or restorations would put the revisions under the same page ID as the deleted page with the same page title. Thus, once a revision has a certain page ID, it will have that page ID forever. In this way, revisions deleted from a page that remains active (i.e. a revision deletion event) will be treated the same way as revisions deleted along with all the other revisions in the page (i.e. a page deletion event). Relevant questions would be, what inconveniences are posed by having (a) page and (b) revision page IDs for a page title change with recreations and restorations; and what inconveniences are posed by having those page IDs *not* change? For example, are references to those page IDs stored in other database tables (of the core or extensions), so that those fields would need to be updated too when creation, restoration and deletion events occur? Are there some bots or other third-party tools that store page IDs and make API queries using them, whose work would be easier if the page IDs stayed the same? It might sometimes be desirable to query by page ID rather than page title, since page titles can change when pages are moved. Despite all these revisions having the same page ID, it would always be possible to undo a deletion or undeletion event easily, because the revision IDs of the group of revisions deleted/restored in a log event would be stored in a logging table field (e.g. log_params). If it were desired to split off some revisions from the page and move them to another page's revision history, that could be done too, using that same data; and it could be undone just as easily. So, for instance, suppose a vandal moves "foo" to "bar" and then the page is deleted; then "bar" is recreated, so that the two revision histories share a page ID. The "foo" revisions could be moved back to "foo" using the data in log_params. Also, because the logid of the deletion event would be stored in the revision table (in the indexed field rev_logid), one could easily select just those rows. What are some examples of scenarios that would involve "title uniqueness annoyances" if the new field proposal were implemented? -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
