Lightning wrote:
Hmm I see where you are going, but that looks like it
generates one
e-mail per article, per user, this would generate a huge e-mail load.
Sure, then grab the names & e-mails first and just use user_id to group on.
Also, since its feeding from cur_id on recent changes
this
would cause the subscription feature to just grab the last change
correct?
Nope. See below...
where can i find osme documentation on the RC table. i
looked in the
docs but that particular part is absent in schema.doc
Use the source, luke! :)
Off the top of my head... The fields mostly look like their counterparts
in cur, but some notes:
rc_bot is '1' for edits by a user account with 'bot' in their
user_rights. These edits are by default hidden from recentchanges; this
was done in response to complaints about the Rambot US cities edits last
year.
rc_cur_time... I don't think it's used right now, but I think this was
meant for grouping edits by page. The timestamp of the _current_
revision of the given page.
rc_cur_id is the cur_id of the _page_ edited. This remains for old edits.
rc_last_oldid: points to the old_id of the previous edit. Used for
producing diff URLs.
rc_this_oldid: For still-current revisions, this is 0. When a new edit
is saved, the previous edit is moved from cur into the old table and
gets an old_id assigned to it. Its corresponding entry in recentchanges
is updated so its rc_this_oldid points to that version's old_id.
-- brion vibber (brion @
pobox.com)