LP#
1712854: Speed improvements for two hold interfaces
The Hold Shelf and Record -> View Holds interfaces are painfully slow when
faced with a large set of holds. The main reason is the 2-stage process used
to gather the data: 1) find hold IDs for the context 2) for each hold, fetch
all the requisite data using a relatively slow API.
Here we create a new API that provides a streaming response of pre-inflated
hold data. The full result set is loaded immediately, and once loaded, the
grid makes use of the "clientsort" feature to provide fast sorting without
the need to go back to the server when only changing the sort columns and
direction, and when paging through results. The Hold Shelf UI now has a
progress indicator that appears whenever the hold list is retrieved from the
server, and the progress indicator for the Record -> View Holds UI is enhanced
to provide more granular updates.
It is expected that other hold interfaces will be able to make use of this new
API for performance and functionality improvements.
NOTE: This includes an additional change required to protect localStorage from
overlarge values when attempting to save the "last printed value" for future
reprinting. Previously, when attempting to print a 2000+ hold list,
localStorage throws an error and the print fails. Now the print will succeed,
but the value is not stored for reprinting and a message is logged to the JS
console.
NOTE: The original development plan was base this a new API on a native
Postgres materialized view, and provide a LISTEN/NOTIFY daemon to monitor for
events that should trigger a refresh of that view. As it happens, the use of
other new Postgres features (primarily the LATERAL join type) allows us to
avoid that maintenance and run-time complication.
Signed-off-by: Mike Rylander <mrylander@gmail.com>
Signed-off-by: Kathy Lussier <klussier@masslnc.org>
Conflicts:
Open-ILS/web/js/ui/default/staff/services/hatch.js
Signed-off-by: Bill Erickson <berickxx@gmail.com>