Wide Holds API Could Use a "Total Count" Variant
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Undecided
|
Unassigned |
Bug Description
Evergreen 3.8
The new wide holds API "open-ils.
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.
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)); >respond( $count) ;
my $count = {total => $total, retrieved => ($limit and $limit =~ /^\d+$/) ? $limit : $total};
$client-
$limit = ($limit and $limit =~ /^\d+$/) ? $limit : $total; >respond( $_ ) for (@list[$offset .. $offset + $limit - 1]);
$offset = ($offset and $offset =~ /^\d+$/) ? $offset : 0;
if ($total > 0 and $limit > 0) {
$client-
}
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?