Ticket #376 (open enhancement)
Switch read-tracking to a better storage system
- Created: 2011-03-24 10:12:29
- Reported by: Reines
- Assigned to: daris
- Milestone: 2.0-alpha3
- Component: code
- Priority: normal
Using cookies for read-tracking is quick/easy, but inefficient and causes problems when the cookie size grows too large.
A quick hack would be to simply move the serialized value from the cookie to a row in the database - either in the users table just now, or after switching to session based authentication, in the online/session table - though if we're to use the database maybe there is a better structure than just a serialized array...
Another option would be to make use of the new cache layer to store this data, which *might* perform better than putting it in the database. However I tend to consider cache as unreliable and shouldn't be used to store anything that can't be regenerated somehow (i.e. from the database).
Franz 2011-03-24 11:34:40
Alpha1? For the temporary fix, I suppose?
Reines 2011-03-24 11:39:30
It doesn't need to be implemented for alpha1, but I thought it would make sense to consider it at the same time as thinking about creating the session-based authentication system, since the read-tracking data is a form of session-data.
Franz 2011-03-24 11:39:52
For reference, Smartys once explained how to "do it properly". That would mean full unread topic tracking, which of course poses some difficulties.
Franz 2011-11-24 22:57:56
- Owner set to daris.
daris 2011-11-25 07:46:40
Are you interested in phpbb3 implementation of read tracking system ported to fluxbb? (it's almost done)
daris 2011-12-17 08:37:54
I pushed fluxbb-2.0-track branch to the fluxbb repo
Newman 2012-04-16 18:32:26
using cookies are fine, using db storage is insanely retarded for read/track topics. the cookie values can be huge nowadays, especially all the new updated browsers.
Newman 2012-04-16 18:34:29
franz said it just right
"What about new users then? Would they have 20,000 unread topics?"
LOL this is exactly why..
i like more cookie too ( so as not to have 10000 tables )
but database has several advantages :
you can use multiple browser / computer
you can track unread topic from longer ( no need to limit to last connect )
Franz 2012-07-07 19:37:39
- Milestone changed from 2.0-alpha1 to 2.0-alpha2.
xekon 2013-03-20 03:36:51
mmm if I remember correctly, vbulletin has the option to change the method for unread topic tracking.
I think it really comes down to how important it is to you to accurately know which topics you have read and which ones you have not. If you are trying to stay on top of actively moderating your forum then having accurate read/unread status will obviously be Very useful.
The only other factor would be server peformance, and both of these needs will vary from person to person.
So maybe being able to offer either option would be the better way, personally I would rather have accurate read/unread status, and only switch to cookie tracking if site performance becomes an issue.
having more than one option makes me wonder how you would deal with the data in the database if you switched to cookie tracking... maybe there could be an addition option to purge the data that you could go back and click if you like the cookie tracking after trying it out.
I didn't realize phpbb3 had db read/unread tracking, I will have to look at whats being done there and see if I can port the logic over.
Franz 2014-10-30 13:12:15
- Milestone changed from 2.0-alpha2 to 2.0-alpha3.