Brion Vibber wrote:
It doesn't store the last x number of edits, but
rather the last 7
days' worth, occasionally culled.
My mistake. I guess then it should feed from RC.
[snip many queries]
Hmm, that sounds like a lot of trouble to go to; and if the number of
subscribers becomes relatively large, we'll be pumping a lot of
numbers into SQL statements. What about something like:
I was under the impression IN() was highly optimized for that kind of
task. plus I just wanted to keep it simple and readable. But yeah, that
was a lot of querys, however they were very simple and joins can
sometimes be slower than separate queries.
SELECT
user_name,user_email,
rc_namespace,rc_title,rc_user_text,
rc_minor,rc_timestamp,rc_comment
FROM user,recentchanges,subscriptions
WHERE
user_id=sub_user
AND rc_cur_id=sub_page
AND rc_timestamp > $cutofftime
GROUP BY
user_id,rc_cur_id
ORDER BY
rc_timestamp DESC
foreach( $results as $item ) {
if( $item->user_name != $last->user_name ) {
email_last_batch()
reset()
}
add_to_output($item)
$last = $item
}
with of course the same caveats on cur_id use as mentiond for
watchlists. Moves, deletions, and renames need to be specially handled
or things drop off the list.
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.
Thats why I was thinking more of a one e-mail per user listing all
changes. Also, since its feeding from cur_id on recent changes this
would cause the subscription feature to just grab the last change
correct? The core idea in my proposal was being able to list all the
changes to a certain article whithin a given period of time, other wise
this would be exactly the same as the watch list. As for article moves,
Thats why I brought up the point of article id's so an internal link to
an article by id would not be broken when the name changes.
where can i find osme documentation on the RC table. i looked in the
docs but that particular part is absent in schema.doc
Lightning