[eluser]jedd[/eluser]
To track where a user is up to in a thread, I use this table:
Code:
# NOTE: only ever one row for any given [ thread_id , member_id ] pairing.
CREATE TABLE member_message (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
watched BOOLEAN DEFAULT FALSE, # Is the member watching /subscribed to this thread?
member_id INT UNSIGNED NOT NULL, # FK to member.id
thread_id INT UNSIGNED NOT NULL, # FK to thread.id
message_id INT UNSIGNED NOT NULL, # FK to message.id
PRIMARY KEY (id),
INDEX (member_id),
INDEX (thread_id),
INDEX (message_id)
);
The table above is what is referred to in the get_last_read_message_in_thread() function in the previous post. Sorry I had to split things up after the forums got confused about the message length.
In my forum controller, well, the previous message's stuff is called from the /forum/threads/ method, but when I start to actually read messages, I have this bit in the messages controller to update the 'last read message' info:
Code:
// extract from forum controller, message() method
$last_message_id_shown_on_this_page = $data['messages'][$last_array_element]['id'];
$this->Message->set_last_read_message_in_thread ( $this->my_id , $thread_id , $last_message_id_shown_on_this_page );
I reasoned it was more sensible to control this update from the controller, partly because of the complexity introduced by pagination, and the fact that my model functions might not always be doing their calls for the current logged-in user. Of course, you can grab full source on that URL I mentioned earlier if you want more context.
I'm also thinking that whenever a user goes to read a thread that is older (most recent message's age) than a given age - probably 1 month - it'll lock that thread. Thread-locking will involve going through the above table and rows with that thread #.
Periodic cron-style jobs can be run to catch everything else.
Any thread that is locked will appear as read (the default case). Any thread that isn't locked, and does not appear in this table, will be considered to be unread / new.
Thread-watching is something else entirely, and I made a mistake early of trying to hybridise the two features. I had a 'watched' flag in the above table, and just took it out as I think of it as a throwback, but I'm still actually undecided on how to handle watched threads that are locked. For storage reasons, it makes sense to cull them. But it's a trivial amount of space, I guess, and a later-unlocked thread would be of interest to any ex-watchers ... arguably. In any case, watching is a separate function.
So, how far is all this from being useful to you?
