replacing the odd linked-list mechanism of old page versions seems awkward. It could be replaced by simply using revision numbers that would be common to both the "cur" and "old" tables.
Yes, I think the linked-list approach should go. Especially since the current codebase doesn't seem to use it. We saw a while ago that the [[Pim Fortuyn]] article has a broken linked list, probably produced by some database timeout, and yet the history page shows up fine, only the diffs are computed incorrectly.
Every article should have a clean revision number, period. That way, there would be an unambiguous way to the n-th version of some article. The current mixture of oldid and version (look at the links on a history page) is a mess.
Axel
On Fri, May 24, 2002 at 04:59:18PM +0200, Axel Boldt wrote:
replacing the odd linked-list mechanism of old page versions seems awkward. It could be replaced by simply using revision numbers that would be common to both the "cur" and "old" tables.
Yes, I think the linked-list approach should go. Especially since the current codebase doesn't seem to use it.
I couldn't agree more. The linked list is redundant if you assume that every revision has a unique timestamp, i.e., pages are not updated within a second. (In that case even a revision number would be redundant.) I had to make that assumption to get some reasonable SQL on the history page, but that could be easily adapted if a version number would be introduced.
Note by the way that the version number on the history page is in reverse, i.e., the lowest number is the latest version, so that is probably not the number you want to store in the database.
Hmmm, thinking about this it ocurred to me that since old_id is auto_inc I could have used that to determine the order of the versions without making any assumptions at all. :-/ So as far as I can tell we don't even need a version number in the database.
-- Jan Hidders
wikitech-l@lists.wikimedia.org