the count affects only the grid for "pagination" purposes. There's no other
reason to do a count to display a grid.
This means that if you pass cache_count=10, you'll end up not having any
"1,2,3" links at the bottom to fetch the next "page" of results.
Putting that aside, you can pass whatever "
Thanks.
I will test your suggestions.
I am currently working with Postgresql 9.1 and it takes nearly 5 minutes to
count a table > 42 000 000 records.
It will if we can have the option in the grid to not do a count of the
result as it is part of the problem in my case. If for instance the query
check trunk as soon as the Pull Request gets merged
def test3(dbset, request_vars):
##you can retrieve the current query with
##dbset._select(), i.e. dbset is a "db(query)" object
##request_vars are the current request.vars
###so you can check for keywods etc etc etc
###c
currently not but it is planned to be configurable (at the very minimum,
cacheable).
Your method BTW works only if all the table is shown, doesn't take into
account a possible condition passed to the grid (such as db.table.user_id
== auth.user_id) or keyword queries.
I'll start working on tha
4 matches
Mail list logo