Axel makes a good argument that the new code's simplified layout
of the Recent Changes page (see
http://www.piclab.com/newwiki/wiki.phtmltitle=Special:Recentchanges )
really is an important loss of functionality. Since his comment, I
added an article history link, but I think his comment still applies
in general. I think it is of critical importance that this feature
be optimized both for function and for speed. I don't want to put
the old code back because it's a dog, but if I can find a way to
implement the needed features in a faster way, I'm all for it.
First, I'd like to solicit an opinion from Jan or other database
gurus about what might make the speed better. Currently, it is
driven by a single SELECT from the current article table, which is
sorted by reverse timestamp (on which there's an index), and with a
LIMIT. The old (N changes) feature also required accessing the old
versions table and an expensive GROUP BY, which I'd like to avoid if
possible.
One way I might do that is to create a new "changelog" table, updated
on each page change. This would hold the information needed for the
RC page which would avoid having to hit the article table or the old
versions table at all. It would use basically the same query (by
reverse timestamp). It might even be able to do the GROUP BY faster,
but if not, it would still have the advantage that multiple changes
to the same page would all show up in the list at their appropriate
position, which might actually be better, because that would also
show the person changing it and other stats which are now buried in
the (N changes).
Jan, would the increase non-atomicity of the article save process be
a problem? MySQL doesn't have transactions, so it's possible that
either an aritlce might be saved while recording that fact in the
changelog fails, or vice versa. I can't think of any real negative
consequences of that (each article's history list would still be
accurate, because those go straight to the article tables).
Any other ideas?
0