Last modified: 2014-11-12 17:17:20 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 T41675, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 39675 - Add primary key and log fields to archive table; perhaps also use original page_id when page is restored?
Add primary key and log fields to archive table; perhaps also use original pa...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.20.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nathan Larson
: schema-change
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-27 02:27 UTC by Nathan Larson
Modified: 2014-11-12 17:17 UTC (History)
7 users (show)

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


Attachments

Description Nathan Larson 2012-08-27 02:27:26 UTC
I offer the following proposed/possible changes for discussion, before I write the implementing patch:

(1) Add to archive table these fields:
* ar_id (primary key)
* ar_log_id (the log_id of the deletion action)

(2) What about these fields? Is there a need for them or can we just rely on JOINs with the logging table?
* ar_log_timestamp (time of deletion)
* ar_log_user (deleting user id)
* ar_log_user_text (deleting user name)
* ar_log_comment (deletion reason)

(3) Would it be better to restore deleted pages to the same page id they had originally? That page id is stored in ar_page_id.
Comment 1 Dereckson 2012-08-27 08:52:49 UTC
Thank you for these ideas.

To submit a patch, if you don't already have a developer access, please require one at https://www.mediawiki.org/wiki/Developer_access

You'll then be able to submit your code to our code review system (we use Gerrit).

________________________________________________________________

(1) Could you give a sample of a query with a performance gain for these new indexes?

(2) The fields you noted doesn't seem to be currently in use in core. I haven't checked extensions.

(3) Could you document pro/cons to use old/new page id?

________________________________________________________________

[ Adding schema-change keyword. Priority: normal. Confirming the bug.

Bug assigned to bug submitter, as he offers to prepare a patch. ]
Comment 2 Nathan Larson 2012-08-28 07:31:17 UTC
(1) The reason for adding a primary key is because, according to Brion's comments at https://www.mediawiki.org/w/index.php?title=Proposed_Database_Schema_Changes&diff=48189&oldid=48188 , not having a primary key "is generally annoying, and means that we refer to deleted revisions with a (namespace,title,timestamp) tuple which isn't guaranteed to be unique. (Dupe timestamps can occur in a page's history due to funny bugs or history merging from two formerly separate pages; very quick consecutive operations may also produce dupes on second-resolution timestamps.)"

(2) I'm sorry, I didn't make clear that I was seeking to open discussion on whether we should add those four fields (ar_log_timestamp, ar_log_user, ar_log_user_text, and ar_log_comment), which do not presently exist; and/or add ar_log_id. Do we need all that stuff from the logging table, or will it suffice to just store that ar_log_id so that row in the logging table can be looked up by that primary key (log_id)? The purpose is largely to help sort out different sets of deleted revisions from the same page; this is important if we're going to implement suggestion (3) below, because we won't be able to distinguish them by ar_page_id anymore, since going forward they'll all have the same ar_page_id. (We'll still need to keep ar_page_id for backward compatibility.)

(3) Pros: It seems logical that page IDs shouldn't change, if we can avoid having them change, for the same reasons that good URLs shouldn't change. If anything references those page IDs, it's helpful to have it continue referencing the same page when it's restored. Cons: I haven't thought of any yet.
Comment 3 Dereckson 2012-08-28 11:05:58 UTC
[ Adding Asher Feldman as cc, to get performance advice. ]
Comment 4 Nathan Larson 2012-10-23 17:37:55 UTC
What changes would people like to see to Special:Undelete and ApiQueryDeletedRevs? For example, do we want to add some filters or sorts to Special:Undelete or some more modes and parameters to ApiQueryDeletedRevs, to search through revisions by such criteria as deleting user, deletion timestamp, deletion summary, deletion action (i.e. logid), etc.?
Comment 5 Aaron Schulz 2012-10-23 17:41:39 UTC
We could use more discussion on http://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion. I wouldn't invest to much time into that table unless redoing it entirely.
Comment 6 Nathan Larson 2012-10-23 17:49:40 UTC
Follow-up to comment 4: Also, Special:DeletedContributions.
Comment 7 db [inactive,noenotif] 2013-02-10 12:14:00 UTC
related bug 26123
Comment 8 Gerrit Notification Bot 2013-10-17 17:50:31 UTC
Change 51675 merged by jenkins-bot:
Add archive, externallinks PK

https://gerrit.wikimedia.org/r/51675
Comment 9 Gerrit Notification Bot 2013-10-28 22:11:19 UTC
Change 92433 had a related patch set uploaded by saper:
Add ar_id and el_id sequences for PostgreSQL

https://gerrit.wikimedia.org/r/92433
Comment 10 Gerrit Notification Bot 2013-11-17 21:36:11 UTC
Change 92433 merged by jenkins-bot:
Add ar_id and el_id sequences for PostgreSQL

https://gerrit.wikimedia.org/r/92433
Comment 11 Andre Klapper 2013-12-04 14:10:05 UTC
All patches have been merged. Is there more work to do here (if yes: What exactly?), or can this ticket be closed as RESOLVED FIXED?
Comment 12 Nathan Larson 2013-12-04 18:40:39 UTC
Some of the other proposals, such as ar_log_id, didn't make it into the final patch (I can't remember why; it may be that I decided it was too much stuff to put in one change). But those other proposals could become a moot point depending on what ultimately happens with the page deletion RFC.

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


Navigation
Links