Comment 13 for bug 1315552

The problem stems from the db stored proc called evergreen.ranked_volumes() and the fact that it no longer (and maybe never, but it's been wholly rewritten at least once) does what it says on the tin. It mixes volume-level information (id) with copy-level information (circ lib name), and is basically useless (now) for the internal uses to which it is currently being put. This is because it does not actually spit out ranked volumes at all, but volume+copy.circ_lib, and volume id is duplicated in the case of differing circ and owning libs.

There are a few ways to address this:

 1) We can notice the duplicates in the output of unapi.holdings_xml() while in the TPAC code.
 2) We can ignore duplicate volume IDs in unapi.holdings_xml() while preserving the true "volume" rank order displayed today by taking the "best" ranking for each volume. Then create a function that ranks copies of a volume, and use that in unapi.acn() to include copies.
 3) We can "fix" ranked_volumes to return more information, such as adding copy id and relevant library ids, so that direct callers can ... **mumble mumble** ... more complicated query.
 4) We can break the unapi structure and invert the volume->copy structure so that copies have volumes dangling off them. We'd still need (3) or something like it for this to work properly.
 5) Something else?

(4) is both the most disruptive and most "correct" solution, IMO. It could be made a bit less painful by leaving the "holdings_xml" include option as-is and adding a new include option that differs in shape. Perhaps "title_copies", since it would be nominally attached to the "title" (bre).

Thoughts?