Fork me on GitHub
Subscribe 6

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).

History

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.

http://fluxbb.org/forums/viewtopic.php?id=3016

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)

https://github.com/daris/fluxbb/tree/fluxbb-2.0-track

daris 2011-12-17 08:37:54

I pushed fluxbb-2.0-track branch to the fluxbb repo

daris 2012-01-23 10:20:02

Commit 6c825f6 to fluxbb fluxbb-2.0-track

#376 Fix redirecting to the first unread post for topic

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..

arw 2012-04-16 19:31:37

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 )

  • cookie size might be "huge", but cookie is transfered at each http request ( there is localStorage which is better but javascript must be used and it's not in old IE )

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.

cookies do limit the number of topics you can track as read, battle.net forums use cookies, and if you click into all topics on one page, then goto page 2 and click into all those topics, the topics you clicked into on page 1 start getting bumped off the cookie. so its somewhere around 75 topics, it would probably vary because of the length of the topic id number.

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.