Recently I’ve had to develop forum software for a website, and one problem we ran into was the most robust way to track unread posts.

After giving this some thought, I came up with two feasable options. We’ll start by taking a look at the first.

Pure Post Tracking

Method one is to create a table:

“forum_views”
postID (IntegerField)
userID (IntegerField)
Index (postID, userID)

Everytime a user would view a post (that was marked as unread) we would insert a row into the table. To output the list of posts, or threads, we would be join the thread with this table.

Cons:

• In order to show the list of threads, or forums, you have to use a LEFT JOIN with the Thread and Views table (even on the forum index) which can be extremely slow on high load websites.
• A different queryset is used for each user, so there’s no worthwhile caching for this method.
• Upon viewing a thread you have to perform a query for each post that is marked as unread.

Pros:

• It gives exact tracking on if a user has viewed a post.

Obviously, the pros do NOT outweigh the cons, so let’s move on to the other method:

Session Time Tracking

The idea of this is simple, and extremely quick. Our first step is to modify our User table if it’s not already setup properly. We need to add one field:

“users”
lastVisitTime (DateTimeField)

Ok now we have a field in our users table, which tracks the last time they visited the website. Now, obviously, the first obstacle is keeping the last visit time, as the time they last visisted the site, and not the last time they viewed a page. The way we will do this is quite simple:

1. First and foremost, we validate their login details, if they’re not anonymous.
2. Next we check for a session variable, let’s call it “user_lastvisit”.
3. If this variable does not exist, we will set it to the data in our table for lastVisitTime, or -1 (if they’re anonymous, or have no lastVisitTime)
4. If they are not anonymous, we now need to update our User table lastVisitTime with the current time.

Now, as you can see, we have the session variable, user_lastvisit, and we can use this in our template, or view, in a loop over all of the cached query results, to see if the last reply time is greater than the last visit time.

Cons:

• It’s generic tracking; the minute the session is destroyed it marks all threads as read.
• It does not track on a per-thread basis, although it could be combined with example #1 to do so.

Pros:

• Extremely robust and quick, works well with caching solutions.
• No large database overhead for tracking views.
• No added database load for marking threads as read.

If you want accurate tracking, I would recommend tracking views as said in example #1, with the views table, and then using example #2 for tracking on lists. The accurate tracking is most notably usable in search results.