Last modified: 2014-01-02 10:38:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28123, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26123 - Special:Undelete doesn't use ar_page_id
Special:Undelete doesn't use ar_page_id
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 28124
  Show dependency treegraph
 
Reported: 2010-11-26 00:22 UTC by MZMcBride
Modified: 2014-01-02 10:38 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MZMcBride 2010-11-26 00:22:07 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.
Comment 1 Roan Kattouw 2010-12-02 15:59:06 UTC
As pointed out by Brion on another bug, this becomes problematic when a deleted title has multiple old page IDs.
Comment 2 Platonides 2011-03-19 23:07:15 UTC
It makes sense placing the deleted revision in different blocks if they have different ar_page_id.
Comment 3 Rich Farmbrough 2011-03-20 18:36:01 UTC
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.
Comment 4 Platonides 2011-03-20 20:44:31 UTC
What'a an OOO risk?
Comment 5 MZMcBride 2011-04-12 22:48:55 UTC
(In reply to comment #4)
> What'a an OOO risk?

Fairly sure he means "out of order."
Comment 6 Roan Kattouw 2011-04-17 08:15:22 UTC
*** Bug 28553 has been marked as a duplicate of this bug. ***
Comment 7 db [inactive,noenotif] 2011-04-17 08:39:25 UTC
When reuse the ar_page_id, please also look at the ar_parent_id. Thanks.
Comment 8 Roan Kattouw 2011-04-18 19:44:50 UTC
(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.
Comment 9 Rich Farmbrough 2011-06-19 12:22:20 UTC
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.
Comment 10 Roan Kattouw 2011-06-19 12:51:50 UTC
(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.
Comment 11 Rich Farmbrough 2011-07-17 07:56:41 UTC
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.
Comment 12 Graham87 2012-11-29 12:17:48 UTC
(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.
Comment 13 Graham87 2012-11-29 12:32:23 UTC
I've mentioned this bug in the Wikipedia manual: http://www.mediawiki.org/wiki/Manual:Page_table#page_id

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links