Suppose we have 10K rows and pager=100:
6.x-1.0-alpha1 works in right direction to display Drupal pager and only apply table sorter for 100 rows, but 6.x-1.x-dev leave Drupal pager caused unfinished loading for huge table.

I think we should disable tablesort-pager and use Drupal pager. So, only 100 rows applied by tablesort rather than 10K rows.

Comments

rooby’s picture

rooby CreditAttribution: rooby commented

The whole point of this is to use views tablesorter, including the pager.

If we don't use the pager then sort doesn't work properly, you are only sorting the subset of results that are on the current page.

I will look into using the regular pager as an option you can select.

Also, this issue #874738: Add a sort progress message for sorting large tables goes part of the way to a remedy for this.

Is this a bug because of the time it takes to render the table / sort the table? If so, and it isn't some other bug this will be a feature request to add an alternate option to the views tablesorter pager.

rooby’s picture

rooby CreditAttribution: rooby commented
Category: bug » feature
Priority: Critical » Normal

Changing to feature request as this would be adding additional functionality, not fixing existing functionality.

After our other conversation I'm not sure I originally understood your request.
Are you asking for an option to use the drupal pager along with the db api for tablesorting?

rooby’s picture

rooby CreditAttribution: rooby commented
Status: Active » Postponed (maintainer needs more info)

Postponed due to waiting for an answer to #2.

drupalnesia’s picture

drupalnesia CreditAttribution: drupalnesia commented

As I mention earlier, suppose we have 10K rows and pager=100 (in Views pager setting). Since new version including the original tablesorter pager (not using Drupal/Views pager) then this module load all rows, right?

If my asumption for "load all 10K rows" right then this make very2 long time processing, even we only need to see 100 rows, that's why I suggest to look into DB API since Drupal has db_rewrite_sql (or page_query ?), so we only need to load 100 rows rather than 10K.

This doesn't happen on 6.x-1.0-alpha1 version. Sometimes when integrated a third party libs we need to modify the way of its process to Drupal way, hope this make a clear explaination.

rooby’s picture

rooby CreditAttribution: rooby commented
Status: Postponed (maintainer needs more info) » Active

Yes, when there are more rows than will fit on one page all rows are still pulled from the database, then you are just displayed the first page by use of the tablesorter jQuery. THi sis how the tablesorter plugin works. It is how it is meant to work.

Drupal's DB API is useful for some reasons, like the fact that it only loads whet is needed for the current page. The drawback is that every time you sort or change pages you are doing a new sql query.
The views module provides a table view using this db api method, also with the ability to use ajax so there is no reload of the page (but the sql still runs).
The purpose of this module is to not have to reload the page and not have to run any sql when sorting or changing pages.
This is why if you have tables with many thousands of rows and tablesorter is taking too long it might be better not to use tablesorter for that view and just use a regular views table instead.

I guess the main thing is that I don't see how you would integrate using the drupal pager and the tablesorter plugin together. The tablesorter and drupal db api methods of tablesorting are both totally different.
I don't see how it would work because if all the rows aren't loaded to start with you cant sort or change pages without a db query, which means you are sorting using the query, not the tablesorter as is the point of this module.

I'd be happy to look at patches or proposed solutions though if you or anyone else have any ideas.

Also, as far as I can tell the tablesorter pager was utilised in the same way for alpha 1. This module definitely never used the drupal pager.