Last modified: 2005-06-17 23:51:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 603 - Delete + undelete cycle doesn't preserve old_id
Delete + undelete cycle doesn't preserve old_id
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 181
Blocks: 1932 454 507 536 1891
  Show dependency treegraph
 
Reported: 2004-09-29 19:23 UTC by Brion Vibber
Modified: 2005-06-17 23:51 UTC (History)
2 users (show)

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


Attachments

Description Brion Vibber 2004-09-29 19:23:12 UTC
The old_id revision ID key is the closest thing we have to a unique, persistent
revision identifier (though currently problematic due to not being assigned
until the next revision is saved).

Currently the old_id row identifier is discarded on deletion, and thus on
undeletion a new number must be assigned. This breaks stored links to those
particular revisions.

A possible fix is to extend the archive table to store old_id and restore it,
however this would still break sometimes with selective restoration (see bug
507): a formerly old revision may be restored to the cur table, where it would
still lose its old_id.
Comment 1 Rowan Collins [IMSoP] 2004-10-30 14:18:06 UTC
Marking bug 181 as a dependecy (lasting ID for latest revision; implemented in
forth-coming schema redesign). This eliminates the problems with selective
restoration, since if every revision has a unique ID, that ID can be preserved
across deletion and restoration, independent of other revisions around it, or
whether it goes from being "old" to "current".
Comment 2 Brion Vibber 2004-12-04 19:02:46 UTC
Bumping to 1.5
Comment 3 Wikipedia:en:User:Paddu 2004-12-19 13:55:20 UTC
Bug 454 and bug 536 workaround this by using timestamps instead of old_id. Does
resolution of this bug allow a more efficient implementation of bug 454 and bug
536? In which case, how should this dependency be expressed? Those bugs have
been closed & might be forgotten by the time this bug gets resolved.
Comment 4 T. Gries 2004-12-19 15:55:03 UTC
(In reply to comment #3)
> Bug 454 and bug 536 workaround this by using timestamps instead of old_id. Does
> resolution of this bug allow a more efficient implementation of bug 454 and bug
> 536? In which case, how should this dependency be expressed? Those bugs have
> been closed & might be forgotten by the time this bug gets resolved.

It will not be forgotten, as I still improve the 454 (Enotif) by optimising the
watchlist accesses of it. However, you are right. I also think, that a "sticky
revision number" as proposed in this 603 would help to optimize the 454 and 536 bug.

When mailing an Enotif, the notification mail is already sent including a
pointer to the last visited revision number by directly pointing the watching
user to the diff view; however, this old_id is (unfortunately) at the moment not
saved by MediaWiki. I was reluctant to introduce just another column in
watchlist - because last-visited revision lvr is a property each user's watched
page and Brion and others would not like me to introduce too many changes at once.

In my opinion, the implementation of sticky version numbers will help to
determine the "seen/not yet seen" status for watched pages quickly; the email
notificationtimestamp has been found to give this information "for free" - while
writing Enotif, I discovered that this side-effect could be used for showing the
new (beamy) "updated (since my last visit)" marker; "for free" means: without
any additional database column.

In other words: 

I like both:

1. email notification timestamp (as it holds property invariant to old_id problems)
2. sticky (invariant, unique) old_id revision numbers (this can only be solved
in database scheme redesign)

I confirm at the moment, that a solution to bug 603 *could* avoid the
notificationtimestamp.
Tom
-- developer of enhancements "ENotif (EN)" bug 454 and "EAuthent (EA)" bug 866
-- merged into CVS HEAD 1.5
Comment 5 Brion Vibber 2005-03-22 22:20:55 UTC
Fixed for 1.5 in HEAD. rev_id is preserved in ar_rev_id on deletion and restored on undeletion.

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


Navigation
Links