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