Staff catalog holdings counts can be very slow/bulky

[Bill Erickson]

Evergreen 3.5

The Angular staff catalog uses UNAPI web service to retrieve copy count information for the search results page. To do this, it request the "holdings_xml" format, which includes both copy count and call number data. In cases where a record has many call numbers -- issue discovered testing People magazine with 2500 call numbers -- rendering the results page can be very slow. It's parsing a 1.4K XML document to extract 2 numbers -- not the best tool for the job in this case.

Earlier code used the open-ils.search.biblio.record.copy_count and related APIs to collect this information. I propose we do the same for staff catalog. Additionally I'd like to create a batch version of the API so we can use a single API call to collect copy count data for a page of result records.

[Bill Erickson (berick)]

Note the work on this has expanded to include bug #1849523 and a bit more. In general, I'm packaging the the data collection for each bib / metabib record into an API that can return a stream of precompiled results so the UI is not required to make so many API calls and do so much data munging.

[Bill Erickson (berick)]

Code pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1889694-staffcat-record-summary-api

From the commit:

==
Replaces a number of result page and record detail page API calls with a bespoke API that returns data required to display bib and metabib record summary information in the catalog.

Specifically, a single streaming API this replaces the following:

* fleshed record retrieval
** including record display fields and attributes processing.
* copy count retrieval
* hold count retrieval

The end result is replacing 22 API calls per results page with 2 API calls.

==

In my testing, the speed is equal to or possibly better than the current interface. Another benefit of this approach is each record displayed -- starting at the first result -- is fully formed, which means you don't see the bits of shuffling that occurs as additional data is retrieved asynchronously.

[Bill Erickson (berick)]

Removing pullreq to address and issue I just identified..

[Bill Erickson (berick)]

Issue from my previous comment resolved and pushed back to working branch.

While testing these changes, I found 2 other bugs, which I have addressed in the working branch for this bug:

1. "Results from All Libraries" was not working correctly.
2. Metrecord searches were crashing when compiling the search results highlighting.

Adding pullrequest back.

For testing, it just boils down to making sure catalog search and record summary displays still perform and look the same.

[Galen Charlton (gmc)]

Pushed to master from the combo branch for bug 1869898. Thanks, Bill!