Page MenuHomePhabricator

Delete + undelete cycle doesn't preserve old_id
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal

Details

Reference
bz603

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 6:58 PM
bzimport set Reference to bz603.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

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".

bugzillas+padREMOVETHISdu wrote:

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.