Comment 1 for bug 1956605

Hi Bill,

That's true, but the count that comes back isn't only meant to be the count of all (in-context) holds. That it's used in the UI when there's a limit is an issue, though.

The count is being sent back so that the client side logic knows how many rows it should expect to receive for the purpose of drawing the progress bar, so that the progress bar doesn't seem "stuck" even when there are many holds.

I think it would be reasonable to do the inner-most query without a limit and offset, return a hash instead of a bare count, like this:

  my $total = int(scalar(@list));
  my $count = {total => $total, retrieved => ($limit and $limit =~ /^\d+$/) ? $limit : $total};
  $client->respond($count);

  $limit = ($limit and $limit =~ /^\d+$/) ? $limit : $total;
  $offset = ($offset and $offset =~ /^\d+$/) ? $offset : 0;
  if ($total > 0 and $limit > 0) {
    $client->respond( $_ ) for (@list[$offset .. $offset + $limit - 1]);
  }

and then update the UI logic to use $$count{total} for display and $$count{retrieved} for the progress bar. It looks like there are three client-side calls to touch.

Thoughts?