Wide Holds API Could Use a "Total Count" Variant

[Bill Erickson]

Evergreen 3.8

The new wide holds API "open-ils.storage.action.live_holds.wide_hash" will return a count of found rows as its first response, but the value is capped at the query LIMIT. IOW, if the hold query matches 20 items but a LIMIT of 10 is passed to the API, the "count" value returned will be 10 and not 20.

It would be handy to augment the API to allow returning the total count, either as an API variant, or by tweaking the existing API to perform an additional non-LIMIT'ed COUNT call.

In practical terms, it means the Holds Count value is incorrect in the record Holds tab in cases where "Pre-Fetch All Holds" is not selected. Similarly, the patron Holds grid in bug #1904036 can show the incorrect holds count.

[Mike Rylander (mrylander)]

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?