Displaying details for records with hundreds or thousands of items

[Dan Scott]

From http://markmail.org/message/g2267j32yz5z7yxp

On Thu, 2009-11-05 at 15:44 -0500, Art W Rhyno wrote:

This is a patch for dealing with bib records that have large numbers of items, a situation which can cause the network to timeout in the opac if the set is too large. At Windsor, this is often caused by microfilm sets, for example, The New York Times [1] has 3527 items, I suspect a better approach for dealing with this is to set up an opensrf call that leverages postgres for doing the paging, but this modifies the rdetail.js file in the opac skin. I have put a simplistic sorting function in place, many of our microform holdings have the year as the final part of the call number, and this sorts the set in order when the call number is in this format.

DCO attached, feedback welcome, and thanks to Dan for pushing us to put forward opac modifications.

[Jason Stephenson (jstephenson)]

This patch or something like it was committed, wasn't it? If so, this should probably be changed to fix released.

[Mike Rylander (mrylander)]

No, but SuperCat (well, unAPI) got the ability to page through the holdings of a bib record, and a new implementation of the copy summary section could be constructed using FeedTemplate (provided by BibTemplate) to make use of this relatively simply.

We might want to provide this as an alternate implementation of copy paging (arguably, it is already, in the conifer contrib branch) but with the ability for the server to do more of the work for us, and the simplification and abstraction of BibTemplate, I'm severely disinclined to apply this. I'm marking it as Opinion for lack of a better classification, and it wouldn't hurt to point this out if someone out there is in dire need of a quick patch that addresses the tons-of-copies problem.

All of that being said, thanks Art for generating this!

[Dan Scott (denials)]

"Opinion" hides this bug from the default search, which is not optimal.

Marking as "Confirmed" because the discussion about how to handle bibs with hundreds of copies has come up a number of times in IRC (it just did again, a few minutes ago) and it is a confirmed bug in all available versions of Evergreen.

Until an alternate working solution is committed, this is a serious deficiency in Evergreen for which Art's patch offers a working workaround - or, perhaps someone will read this ticket and explore the directions that Mike has suggested for a better solution than Art's patch provides.

[Jason Stephenson (jstephenson)]

The patch no longer merges cleanly in 2.0, 2.1 or master. I'm not certain how to resolve the conflicts at the moment, so this one stays a patch for now.

[Jason Stephenson (jstephenson)]

The patch won't apply cleanly in anything resembling a modern installation.