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