Brion Vibber wrote:
Lightning wrote:
Lightning wrote:
Is there a a reaon we don't have an article primary key ID. We have primary numeric keys for revisions in the cur table, whats up with this?
We could do so, but this would require some restructuring of tables and then taking the wiki offline for a full day or so to get it in place. For most intents and purposes, cur_id is the article primary key ID.
Wouldnt using the article name as a primary key be a lot slower
than using a numeric one?
Not much, probably, but perhaps a little.
whooops i feel realllly stupid. old_id == cur_id right ?
Nope.
yeah you see i thought id's were unique to each revision...whoops. But in all seriousness, having each revision have a unique id may not be a bad idea...
That's what old_id is. :)
Is there any chance of restructuring this and adding an article ID at one point? I know its a lot of work, but having to locate articles and revisions by a combination of namespace and title seems hardly efficient. Instead of a quick binary search through an index of numbers we are are running 2 text comparisons, which are just plain slower. I think adding an article ID field would not only have a potentially pretty good effect on performance when moving through revisions, etc, but it would also have the potential to clean up the code internally for some special pages and functions and make then work a lot faster, especially the watch list function.
aside from that, i would like to know if you had any comments on my subscriptions feature idea. I know the pseudo-implementation i presented was erroneous, but oh well I could allways fix it if you liked the idea, as well as making it able to feed from both recent changes table and cur and new so it could be switched according to technical reasons.
Lightning