Last modified: 2005-06-17 23:51:51 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.
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".
Bumping to 1.5
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.
(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
Fixed for 1.5 in HEAD. rev_id is preserved in ar_rev_id on deletion and restored on undeletion.
