Last modified: 2014-01-02 10:38:24 UTC
When using Special:Undelete, it does not take into account the value of ar_page_id when inserting into the page table. This is nasty. If the page doesn't exist ($makepage = true) and the ID isn't already in use (for whatever reason), Special:Undelete should attempt to insert into the page table using the value of ar_page_id.
As pointed out by Brion on another bug, this becomes problematic when a deleted title has multiple old page IDs.
It makes sense placing the deleted revision in different blocks if they have different ar_page_id.
The page id is less important than the revision ids. Additional work will be needed after this bug is fixed to determine where (if anywhere) on WMF projects an OOO risk in history occurs.
What'a an OOO risk?
(In reply to comment #4) > What'a an OOO risk? Fairly sure he means "out of order."
*** Bug 28553 has been marked as a duplicate of this bug. ***
When reuse the ar_page_id, please also look at the ar_parent_id. Thanks.
(In reply to comment #3) > The page id is less important than the revision ids. > > Additional work will be needed after this bug is fixed to determine where (if > anywhere) on WMF projects an OOO risk in history occurs. This has nothing to do with order, and out-of-order issues cannot happen. Order is determined by timestamp, not at all by page ID.
Reassure me that the time stamp is sufficiently granular that the revision ID is NEVER needed as a tie breaker, which is what I was referring to. Clearly, if page ID was the only method of determining order, things would be horribly broken, equally clearly they are not, so my assumption was that the time stamp was at least primarily used. This was all implicit in my statement "to determine where (if anywhere)" was the request above. Does the time stamp suffice everywhere? And of course determining this may not be trivial, since the source of the time stamp needs to be taken into account, even two machines running from the same local ntp service will generate a percentage of out-of-order timestamps, depending on the granularity.
(In reply to comment #9) > Reassure me that the time stamp is sufficiently granular that the revision ID > is NEVER needed as a tie breaker, which is what I was referring to. It's not, but then that issue exists already. > Clearly, > if page ID was the only method of determining order, things would be horribly > broken, Yes, they would be. Which is why no one is proposing the page ID be used to determine the order of anything. It's simply proposed that the page we create to give restored revisions a home get its old page ID back. To reiterate: this proposal is about restoring page IDs when restoring revisions. It wouldn't change the existing behavior concerning timestamps or revision IDs or anything else that's used for ordering. Therefore, there are no out-of-order risks because ordering isn't touched. equally clearly they are not, so my assumption was that the time stamp > was at least primarily used. This was all implicit in my statement "to > determine where (if anywhere)" was the request above. Does the time stamp > suffice everywhere? And of course determining this may not be trivial, since > the source of the time stamp needs to be taken into account, even two machines > running from the same local ntp service will generate a percentage of > out-of-order timestamps, depending on the granularity. Yes, timestamps aren't perfect, but that's an existing problem that won't be made any worse (or better) by the requested feature.
OK so my original comment was valid (if ill-informed). What I am still unclear about is whether undeleted pages use the old revision IDs (I can't see why they wouldn't), if so my issue goes aaway.
(In reply to comment #11) > What I am still unclear about is whether undeleted pages use the old revision > IDs (I can't see why they wouldn't), if so my issue goes aaway. Yes, they do, for all revisions deleted in MediaWiki 1.5 or later.
I've mentioned this bug in the Wikipedia manual: http://www.mediawiki.org/wiki/Manual:Page_table#page_id
