With the new behavior of using the ar_parent_id values for undeletion (see T183375 and T193690), undeletion can now make revisions with "broken" parent IDs that do not point to an existing row in the revision table. Such revisions will show a green positive number in the history and user contributions pages as if they had parent ID zero. An example of such a revision on Wikipedia is revision 823434018, whose parent ID is 818256990. We need to create a maintenance script that will change all the "broken" parent IDs to either the "most obvious value" (given by the previous revision by ID or timestamp) or zero (to make them be actually treated as creations of new pages, with the "N" mark in the user contributions page).
Description
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T186280 Create maintenance script to fix "broken" parent IDs | |||
Stalled | None | T193690 RFC: How should we fix the undeletion system? |
Event Timeline
Comment Actions
Can anyone please do an SQL query that prints out a list of revisions on Wikipedia whose rev_parent_id is not the rev_id for an existing row in the revision table, but instead the ar_rev_id for a row in the archive table, that will be affected by the script?