Closed JoostvDoorn closed 5 years ago
Thanks for your contribution @JoostvDoorn :) I am not against the idea, it goes with my belief that HEAD requests are responsible of total counts, so why not do a PR if this works for you.
I find the change makes the code messier than it already is. Maybe we should only present the total count, and skip the option to count the rows after filtering. That would make the code a lot simpler. Does the datatables spec have anything to say on this? Will the pagination break if the presented row count is larger than available in the filtered set?
I was considering doing a pull request after #110 was merged, also I would put a bit more effort in making this code more generic/clean. For proper pagination you will need to provide the count corresponding to the number of pages that you want to display pagination for. So if you use the total count it will allow you to navigate to more pages than exist in the filtered set.
Depending on the exact circumstances, it is also possible to approximate the filtered row count via estimation or by making the appropriate indexes. See e.g. here
Closed old issue
We run into some problems when our tables get too big because of the count on the filtered query is pretty slow. As we don't allow jumping to the last page, but just allow basic filtering and sorting we do not want to calculate the full count. I have implemented a few simple modifications to suits our needs here: https://github.com/JoostvDoorn/sqlalchemy-datatables/commit/da2ef8eb6a5a839cc935e8e19e38eb2a890f41c0, but something similar would probably be useful to others as well.
It would be useful to know what requirements other people have for such a feature so I can make a pull request.