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