Comment 1 for bug 1662597

Also adding Mike Rylander's suggestion from bug 1629108 for addressing this issue:

Today, the search code returns a field containing the constituent bib if only one matches the requirements of the search. If there are more than one, that field is null. That's used to facilitate jumping straight through to the bib from the result screen.

I think to address this we'll probably need to add a field to the result that contains the list of relevant constituent bibs, and then pass this back somehow to unapi.mmr_holdings_xml code when getting the XML of the holdings. While that stored proc is already "special" and there's no real worry about making its arguments unique, the unapi.mmr stored proc is meant to match the other real-object unapi calls and it's parameters really shouldn't change.

To get that information back to the unapi code we could probably use a specially formatted string passed via the includes parameter. That would let us avoid changing the function signature, and should be fairly straight forward to use on the perl side. While "includes" is usually used to specify the types of objects we should embed, I think it could be useful to invent a general purpose encoding for specifying both the type and the specific IDs to include. I'm pretty sure that could be built in a backward-compatible way.