Welcome Guest, Not a member yet? Register   Sign In
Forum system - how to track already read vs new messages, per user
#41

[eluser]jedd[/eluser]
Ah, I'm sorry - I misread. I thought you were asking how you identify from a list of threads - ie, within a forum - which ones have unread messages.

Okay .. well, what do you have so far? Do you have something similar to my message# / thread# / user# correlating table to track where users are up to within a thread?

If you do, then (outside of de-normalising your database fairly savagely) I suspect you're going to have to do what I do above - which I do per page of threads - to all the threads within a forum. Using my approach, I could see that becoming increasingly expensive, as I stop monitoring threads that are locked - so I'd have to check if they are old (and locked) or new (and not registered in my message/thread/user table yet).

Do you need to know the number of threads that contain unread messages within a forum, or just if any threads with unread messages exist within a forum? The latter is obviously going to be cheaper to determine.
#42

[eluser]InsiteFX[/eluser]
Hi jedd,

I found this today on the vbulletin board not sure if it will help you.
May give you some ideas.

mark read thread

UPDATE:

Table = forumread

Fields:

user_id

forum_id

time_mark

You will need to update this for the database when a user reads a sub-forum or main forum.
The main forum should not be marked unless all sub-forums are marked or you can use a
different icon to indicate the state for the status of the forums.

Enjoy
InsiteFX


Enjoy
InsiteFX
#43

[eluser]jedd[/eluser]
An interesting article, despite its vintage (and the number of comments from people saying 'this doesn't work'). It looks like they also had a text field in there to track views, which is a bit weird. Not sure what limitations vbulletin imposed/imposes on its developers, though.

I think xwero was suggesting the [ thread / member / date ] combo (as opposed to my thread/member/message, and vb's user/forum/date - actually, how did they check a thread's read-status?). Anyhoo, it's effectively the same approach, but I preferred message # over handling dates for a few reasons. Ints are smaller than dates (at least, I thought they were, but for DATETIME / DATESTAMP this may not be the case). Certainly I reckon there's a cost involved in converting from date format back to internal storage format for comparisons. Mostly I just wasn't sure whether dates were going to be immutable on my messages - I am still pondering relying on table.id for chronology order, with the option to change the date stamp of a given message to reflect the most recent edit.
#44

[eluser]TheFuzzy0ne[/eluser]
I think that what I need to do, is just query the database, and pull out a row for each forum with the highest date, which of course will be compared to the date of the most recent post in that forum. This was suggested before by Developer13, and has one inherent problem - Once the user has read the most recent post in the forum, the forum will appear to be have been read from the outside view of the containing forum. I think I just need to figure out how to get around this. Every idea I come up with seems to loop back around to this idea, so I figured I may as well run with it, iron out the creases and see where I am when the dust settles.

...And Jedd, I don't know if this answers your question, but at the moment I have nothing to do with forum tracking in my database. In the interest of keeping it simple, I would like to keep the forum tracking separate from the rest of the forum, at the expense of an extra query or two. I may decide to change it in the future, but since the site is not expected to be too busy, I'd like to avoid it.
#45

[eluser]InsiteFX[/eluser]
Orginally VB was using cookies for storing the forums read.

From what I got out of it was that they marked the last forum read.
The time was being used to automatically mark all forums read after
a certain date say 30 days. When a user went back into the forum
they were showen the last posted thread.

The problem with using the database is that if the forum gets very
large then it will put a heavy load on the server.

I'll keep looking around for some better solutions.

Enjoy
InsiteFX
#46

[eluser]jedd[/eluser]
Fuzzy - can you clarify - does this mean you have no way of showing a list of threads within a forum, and identifying which of those threads have unread messages too?

I was assuming you'd got that facility, and was extrapolating upwards with that data to identify forum read/unread-ness.

As soon as you go solely by date of visit *to the site*, then you're going to have quite weird read/unread states for your users.

And now it's my turn to be confused - your first sentence sounds like you're pulling out the same bit of data twice, and comparing it to itself. Obviously this isn't what you are doing .. perhaps you could show your current schema? Is the only way you have of tracking a user's progress or status, a date field attached to your user-table, and that reflects the last login (or logout) time?
#47

[eluser]jedd[/eluser]
InsiteFX - I think you have to make the choice early - do you want a good tracking system, or less load on your DB? Wink

I'm curious how EE does it. Are the forums part of the free/trial version of EE you can download? Though these forums do seem to cheat a bit on the way they track read status on threads, and of course, they don't appear to offer an aggregated 'there are unread messages in any thread in a given forum' check, either

I haven't cut any code yet, but have been pondering the relative costs of picking the last x (somewhere around 30) threads in a given forum, and checking if any of those have new messages, and if not, trying the next 30, perhaps giving up after y (say 5) iterations or so. The 'last threads' in a forum would be determined entirely by thread.id, rather than message.date where message.thread_id = thread.id. Ie. an attempt to be slightly smart about it, by reducing the complexity of the sql sub-queries being made, while still likely to catch a forum with threads that have new posts in them.

Again, though, this relies on the presence of a member_thread_message table.

Anyhoo, a bit bizarre to try to keep this stuff in a cookie, isn't it? I guess anything that's dropped off the end you just assume has been read (or 'it's so old, the user doesn't care').
#48

[eluser]jedd[/eluser]
Hi sunny85. I think Fuzzy's complaint is that he always overthinks things too .. so this might not help. Wink

Out of curiosity, can you describe the difference, as you see it, between doing this:
Quote:Table name: has_read
Fields: user_id, thread_id, date_last_read

When the forum member views a thread, the above table should be updated with the forum member’s user id, the id of the thread they are reading and a timestamp.

If the timestamp in the has_read table is greater than the timestamp of the last post in that thread, then there are no new posts for the user to read.

If the timestamp in the has_read table is less than the timestamp of the last post in that thread, then there are new posts that the user has not yet read.

And changing each occurrence of 'timestamp' & 'date_last_read' to message_id in all the above?

I think your second point - the option to flag an entire thread as seen even if you looked at, say, just the first 10 messages (1 page) - is a simple logic choice, and not dependent on whether you use time or message #.

I think if you're presented with a thread of 50 posts, and you read some of them, and you wander away, and a new post is posted - at that point the thread contains unread messages too. I'm not sure how you distinguish between subsequent posts in that thread. Should the system track that you are not interested in that thread ever again (because you've already viewed some, but not all, of the messages in it) or should it re-flag that thread as containing unread messages again?

From a user perspective I see the difference there as pretty subtle.

I think of my usage of these forums as an example. I don't look at every thread, and determine which threads to not look at based on the subject. Until they float off the page (within a day or so) I don't mind that they stay bold - I'm happy to track that in my head. More importantly, I don't really pay attention to whether they get augmented by none, some, or many new messages.

Perhaps if the system tries to be extra smart - an 'ignore this thread forever' option up there next to 'watch this thread'?
#49

[eluser]InsiteFX[/eluser]
You can also give the user a button on the forums, so that they can mark a thread read or mark all read.

One thing you will need jedd is an auth member system for the forum.

I really should take the time and convert my auth system over to CodeIgniter.

Mine is in php 5 code

but it handles:

when a user accesses the site they are automatically given a Guest level until they login.
It also handles multiple Admin's using Roles and handles user Tracking, shows how many users
are online etc.

Jedd, have you decide on the GUI for the forums yet like color?

Enjoy
InsiteFX
#50

[eluser]kurucu[/eluser]
One weekend hiking in the Pyranese and I miss a great debate on my current problem! I've spent the last week pondering this exact problem with myself, and have spent most of that going round in circles.

My current thinking is a table with user_id, thread_id and post_id. Anything without an entry is unread, anything with greater post_ids has unread posts within it. The problem is size and complexity, as Jedd pointed out early on, for very vast forums. I'm not sure what would be presented to guests... perhaps "hot topics" with recent replies.

vBulletin, which actually I administer through another site, allows one of three modes to be selected: cookie time only (threads since last visit), simple DB (threads since last visit, infallible) and fine-grained DB (complete message read tracking). I've not looked at the code for the latter, but generally find vB code to be completely obscure, as they have a unique insight into the meanings of MySQL column types.

Having read all of your responses, I've still not idea what to do, and might just post a note on the forum suggesting that users keep note of read threads themselves! Being serious, my present thinking is implement the user/thread/post solution, and then see how it goes...




Theme © iAndrew 2016 - Forum software by © MyBB