Brion Vibber wrote:
Lightning wrote:
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,
Watchlist uses namespace/title instead of cur_id to better survive the
case of disappearing/reappearing pages.
If a page is deleted, it's got _no_ cur_id. If it's recreated, it'll
have a different cur_id. So if we wanted to handle watched, but
presently nonexistent, items with a cur_id index in watchlist in
general, we'd have to make another table just for those, or weird
non-normal columns in watchlist, and then fix up the watchlists
whenever a page is created / deleted.
That's why watchlist was changed _from_ using cur_id to using
namespace/title.
Oh, yeah. I get it. That never crossed my mind. I completely forgot you
could watch non-existent articles.
I do think
that we should file this into a "TODO at some point" list.
Certainly.
The conversion itself would be quite simple, and
could be done over
time without disturbing the database.
If you mean, we could create a new_old table and make a mess of
spaghetti code to check new_old and old_old and transfer articles'
data one at a time while carefully locking another attempt to do the
same, well hypothetically perhaps.
I was actually talking about the adding of an article_id field, that
should be quite simple. But yeah, combining both tables into one would
be a messy, torturous operation at best if the wiki was not put in read
only mode while the conversion took place. I didn't even go into that
because I know that at this point we can't justify this at all, however
the first step to the transition, which is the adding of an article_id
field to both cur and old doesn't seem that far fetched except for the
slowness of adding a field problem.
I am seeing something like this:
TABLE 'revisions'
-PRIMARY KEY article_id -- (completely new)
-rev_id UNIQUE -- (corresponds to cur_id and old_id)
-parent_rev (the revision this revision was edited from)
....the rest of the fields
/*this table just maps an article to its current revision. editing an
article INSERTS a new revision and UPDATES this table to point to the
new revision. only the current revision may be edited.
*/
TABLE 'current_revisions'
-article_id
-revision_id
////////////
as a side effect this all would allow us to implement a simple 'branch'
system for articles. sort of like we branch source code into stable and
development revisions. this would allow us to for example branch certain
articles to be introduced into nupedia for example. The article is
branched, fact checked, reviewed, and submitted. I am not saying to do
this, I am just saying with a system like this it *could* be done.
almost like CVS for wiki text.
This is just stuff to keep in mind, I know at the moment its hard enough
keeping the website running well under the load to go and mess with all
this, but in the future, they are options to consider
Lightning