|Line 20:||Line 20:|
Using SQL_CALC_FOUND_ROWS is not necessarily better, particularly for indexed queries
Using SQL_CALC_FOUND_ROWS is not necessarily better, particularly for indexed queries[http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?][[User:Tenorviol|Chris Johnson]]
This code does not work correctly as it stores the limitstart into a session variable. So, when clicking upon the first item in your pages list, no limitstart variable is present and so the previously saved limitstart value is reused.
ie. you can go to pages 2, 3, etc. but not back down to 1.
A work around I have used is to always get the value from the Request object.
//$limitstart = $mainframe->getUserStateFromRequest($option.'.limitstart', 'limitstart', 0, 'int');
$limitstart = JRequest::getVar('limitstart',0);
Confirmed and fixed. Thanks. Chris Davenport 23:03, 31 May 2009 (UTC)
I have one question
The example changes to the model seem to call the query twice, once with and once without the LIMIT. Should this not use the same SQL_CALC_FOUND_ROWS method mentioned in the "Examples with JDatabase" section? Crispy 11:49, 28 October 2009 (UTC)
Yes. Please go ahead and change it. Chris Davenport 18:39, 28 October 2009 (UTC)
Using SQL_CALC_FOUND_ROWS is not necessarily better, particularly for indexed queries: To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?. Chris Johnson 23:08, 30 October 2009