bfarber Posted September 25, 2009 Posted September 25, 2009 [quote name='Mat (FDNZ)' date='19 September 2009 - 11:08 PM' timestamp='1253416088' post='1857513'] Couldn't you flip it around and do a short list of forums to put in a MySQL NOT IN() clause? You have the same problems either way (of course, this all depends on how many forums, your config, etc. etc. etc.).
BuddyKidd Posted October 1, 2009 Author Posted October 1, 2009 Is it possible that this will be changed in version 3.0.4?
Management Matt Posted October 2, 2009 Management Posted October 2, 2009 Ok, hopefully I won't regret this. ;) Brandon (Bfarber) is correct in that the today's posters feature did join on a permission index table to generate an appropriate list of forums as this is generally better than a long list of forum IDs in an IN() clause. However... Over the past few releases, we have been removing this join in favour of an IN clause as the join onto the permission index table causes a filesort with a temporary table which, for a very very busy site, is much like flicking on and off the power switch. I did actually originally flip it around and use NOT IN() in a QA build of 3.0.1 but Brandon removed it rightly because the forum IDs that are accessible via $classForums->forum_by_id are only ones that you have viewing permission on before additional checks are peformed (passwords, can you read topics, other users topics, etc, etc) so flipping it around to a NOT IN can actually expose you to more forums you never had access to anyway (staff forums, etc). Anyway, the end result is this: I did to the today's poster feature what I did to search / view new content and removed the table join in favour of IN(). While I was there, I removed forums that do not allow post incrimination thus restoring IP.Board 2.x's functionality and hopefully pleasing more people that the change annoys.
BuddyKidd Posted October 2, 2009 Author Posted October 2, 2009 I thank you so very, very much. I can't wait until 3.0.4 comes out.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.