Brion Vibber wrote:
Well, you kinda hafta use the text when all you've _got_ is the text
that's given to you in a link. :) cur_id is used in various places for
intertable joins already (for instance in the links, brokenlinks and
searchindex tables).
I am more thinking of other internal operations, not just page views.
Specifically I am thinking of watch lists, and history views, although
in the future it could become useful to be able to identify a specific
article (not revision) by a specific primary key. However, I do
understand that the databse load that adding a new column into the cur
and old tables would cause is very much not welcome at the moment. I do
think that we should file this into a "TODO at some point" list.
The conversion itself would be quite simple, and could be done over time
without disturbing the database. Not to mention that, like you said,
eventually combining cur and old would simply the code at various points.
The win of separating it would largely be from being
able to combine
cur and old _revision_ data into a single table, which would save some
trickery on page save / rename / load / diff / contribs /
recentchanges where we have to deal with two
almost-identically-functioning tables.
I don't know what it is so I don't have any comments...
Look in message : "[Wikitech-l] Subscribe to article feature (code
included)" from yesterday. It is basically a sort of e-mail watch list.
except it lists a summary of ALL changed to articles one is subscribed
to over the last 24 hours, not just showing the latest change. If no
changes are made, no e-mail is sent. I know its similar to the watch
list, but the watch list has the problem that one must look at the
article history to see the changes that might have been made in between
the last change and the last time you looked at your watch list. The
script is fairly simple and shouldnt cause too much of a load since it
uses no GROUPing JOINS or anything else like that, just (very) simple
selects. Of course now that you point out to me the lack of a priamry
key for an article (as opposed to revision) It would make the
implementation a bit more complicated, and less efficient. The best way
to understand it is probably by reading the code.
Lightning