ok, lets reset us the question a bit. This "original" issue had a logic because the grid makes TWO queries by default. One is to retrieve the data for a particular page (and there's NOTHING we can do about it) , the other is to count the total of the records disregarding the pagination. Now, if your backend takes a lot of time to retrieve the page-related data you want to show to the user, that a problem you need to fix in your database (or your model, or whatever else). What web2py can fix (and did it already) is to avoid counting the additional roundtrip to calculate the total of records (the count can accomodate all kinds of logics now, fixed value, one of your choice, dynamic, caching it, etc.).
The thing you posted """ Same story here. I like *grid*, I like pagination, however I'm missing the feature of limiting the total number of rows in the output. In my case *grid* can easily generate over 1+m rows in the output, which when paginating by 50 rows per page, would produce 20k+ pages... Who needs that many pages? Who would click 20+k times anyway? """ doesn't point towards something the grid can fix. If records are in your table, and users can see 1 million records because there are no "permission" issues, why would you limit your presentation to only a slice of it ? There's no difference in performances trying to fetch the first 50 records of a 1 million recordset or the next 50. Also, if you don't want your users to reach page 10, then do a simple math (no_of_records_per_page*max_page_they_reach) and set the corresponding value to cache_count. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
