On Feb 5, 2008 7:51 PM, Brion Vibber brion@wikimedia.org wrote:
Roan Kattouw wrote:
On this whole revid vs. timestamp thing: I think I read something a while ago (don't remember where) about adding rev_previd and rev_nextid fields, each pointing to the previous/next revision ID (unless of course it doesn't exist, in which case it would be NULL; does MySQL distinguish between NULL and 0, anyway?). This would make the prev/next links less expensive to generate (only one DB query rather than 3), but would cause an extra UPDATE when adding revisions; also, merging histories could become a nightmare: in a worst-case scenario, merging N revisions into a history of 2N revisions would cause all rows to be changed (3 times as many as is currently the case). Also, filling these fields for existing revisions would be a huge operation (maybe this could be done on the fly?).
There's been occasional talk, and at one point some code went in and I think got taken back out temporarily.
One thing to consider is that we could actually *indicate* those non-contiguous merged sections in some useful way, like a (shudder) tree view....... maybe.... sort of. :D
Everything gets horrifyingly ugly when you try to do anything other than straight timelines, though.
Just thinking out loud here...
If timestamps are not unique, and revisions might not be ordered, wouldn't ORDER BY revision GROUP BY timestamp order it by timestamp, and then by revision number if two or more identical timestamps are found?
That would get around the two-query issue. Or is that too expensive?
BTW, thanks Brion for the detailed explanation! :-)
Cheers, Magnus