Welcome Guest, Not a member yet? Register   Sign In
Building a Read vs Unread Status for a Forum
#1

[eluser]AgentPhoenix[/eluser]
So I'm completely stumped on this one, but I'm sure there are a few people here who can help me brainstorm a solution for my problem.

I'm looking to develop a very basic message board system with CI and I've got a handle on everything except one feature: unread posts. When you come to this forum (or any other for that matter), it highlights the posts you've read, then when you read it, it doesn't show the notification any more. In the same way, if I come here, read a handful of posts then leave, then next time I come back, it still shows the posts I haven't read as unread. So the question is, how? What's the best way to accomplish something like this? Obviously I can store last activity in a cookie or pull it out of the session (storing sessions in the database), but the part that I can't seem to get my head around is how to set something read versus unread like most forums do.

Since these boards are blessed with a few geniuses, I was wondering what kind of avenues you think I should be going down to research this and what kinds of solutions might work best especially with CI. Any help would be absolutely HUGE.
#2

[eluser]whitey5759[/eluser]
Don't most forums just show you a collection of recent posts, posts with alot of activity, and/or unanswered posts? If you are going to the extent of tracking who has read what, then the only logical way I can think of is to store a table with the user ID and post ID that have been read. If it's not in there, then it hasn't been read. Such a table might get alot of rows in it, but if your column types are numeric and indexed properly it will be lightening fast and not negatively affect the performance of your site.
#3

[eluser]JoostV[/eluser]
Or you can have one row per user and store the read posts as a serialized string. Not sure if that's faster, though.
#4

[eluser]jedd[/eluser]
Read through this [url="http://ellislab.com/forums/viewthread/110399/"]four page[/url] monster of a thread on this very subject.

And then come back if you have any questions Wink
#5

[eluser]AgentPhoenix[/eluser]
Jedd, thanks for that link. I can say that I honestly didn't think of doing a search for something like that on these boards. This is going to come in really handy!
#6

[eluser]jedd[/eluser]
Yeah - who'd think to search forums for messages about writing forums, eh?

Anyhoo, the method I describe in there is pretty much done - a few things I need to sort out (locking threads on reads if they're a certain age) and so on - but the design seems to work a treat. Entirely unsure how well it would scale across thousands of threads, thousands of users - but I speculate reasonably well (because of the fact that locking a thread deletes all latest-read info about it for all users) and besides, disk is cheap.
#7

[eluser]andrewtheandroid[/eluser]
just a quick one why not store the timestamp of "last login" for the user.. then compare these with the posts' timestamps? only show the ones that are newer than last login.

edit: ahh i didnt see that link..
#8

[eluser]jedd[/eluser]
[quote author="andrewtheandroid" date="1257459116"]just a quick one why not store the timestamp of "last login" for the user.. then compare these with the posts' timestamps? only show the ones that are newer than last login.
[/quote]

The problem with this approach, btw, is that it assumes a person visits each forum, and reads through every message in that forum, on every visit. It also means you have to track when people leave, rather than when they arrive - this is complicated because it's much easier to track when people arrive than when they leave, and consequently that's all most sites bother with.

I also think that it would be harder - though I have not pondered upon this problem very deeply - to design a self-cleaning system using this methodology - I suspect instead you'd end up with lots of cruft, and/or you'd have to run regular clean-up tasks.
#9

[eluser]andrewtheandroid[/eluser]
hey jedd i "skim read" that article (still took me more than 30min to partially digest) haha.. yeh I now see the folly of my rash answer. hmmm when I was reading the suggestions in my head I sort of thought what I'd do. Lets say we are only really interested in the last (say 30) topics.

Code:
last_read_table (restrict to 30)                     query_result_last_30
userid | topicid | timestamp                         topicid | timestamp

each time the user reads you add the topicid to the timestamp
each time someone creates a new post or topic update timestamp

then compare each table for "read" results. I guess extra fields like last_post_id is needed to link them to the one after they read. so each time they refresh the page you do can pull the last timestamp from the userread table and then search any new updates since last timestamp to make it "less expensive". or you can limit to a smaller size like 10 or 20.

I guess you can have users manually subscribe or bookmark sites in which it searches through that list and tracks changes. Also you could allow the "hardcore" users to set this size limit from 30 to 100.. or something like taht.

I'm curious to know what you decided in the end?! I'm making a new site at the moment and will most likely have to implement a forum so I thought it's probably better to start thinking of these things now that you mentioned them! Thanks for reading.
#10

[eluser]jedd[/eluser]
[quote author="andrewtheandroid" date="1257469573"]
Lets say we are only really interested in the last (say 30) topics.
[/quote]

As soon as you set arbitrary limits for things like this, you strike a whole raft of new problems I think.

I'm not sure from your code sample and subsequent explanation was an adjustment of my idea, or an extrapolation of your original .. but apart from the problems with arbitrary figures (which you hint at yourself) there's the fact that time fields are more complex than integers, especially when you bring in timezones (of course, you tend to keep all database dates and times as local, but still ...).

In any case, I can't see any advantage to tracking via time rather than message number.

What I decided in the end was pretty much what I described in that thread. And you're right - it's much easier if you sort out the design up front - I started a few different approaches in code before I just put it off and let the back bit of my brain dwell on it for a while. There's probably a few things that will be hard for me to implement later, but I think I got most of the interesting functionality sorted (or at least sortable).




Theme © iAndrew 2016 - Forum software by © MyBB