[OPEN-ILS-GENERAL] Reintroducing search range-like features in TPAC

[Dan Scott]

On Mon, Dec 12, 2011 at 10:14:24AM -0500, Kathy Lussier wrote:
> Thanks for taking a look at this Dan!
> 
> >>As for one of the elements of MassLNC's document, requesting that
> >>copies
> >>be sorted first by library name and then by call number, I've taken a
> >>stab in that direction by making a branch such that volumes within the
> >>unapi.holdings_xml database function sort by library name and then call
> >>number label. There is still a loophole: copies that are circulating at
> >>a library that is not the volume owner will still appear out of order,
> >>but at least this moves us closer to the goal.
> 
> I just need a bit of clarification here. When you say "copies that are
> circulating at a library that is not the volume owner" are your referring to
> the circulation library (as entered in the copy editor) or are you referring
> to copies that just happen to be circulating at another library after
> filling a hold? I suspect the former, but, since I initially read it as the
> latter, I want to make sure I'm understanding this correctly.

Right, the former (circulation library as entered in the copy editor).
To jump down to the database level, the remaining problem lies with
copies where asset.copy.circ_lib is not equal
asset.call_number.owning_lib - nothing that an extra dose of SQL can't,
in theory, deal with.
 
> >>As for implementing the "show copies that are held by the preferred
> >>location first" logic, a simplistic approach would be to have the
> >>Template Toolkit layer check for available copies in the holdings_xml
> >>via a specific XPath request and then bubble those to the top - but
> >>that
> >>won't work for sites with lots of copies and a wide search range,
> >>because we'll hit problems with paging. So a better route might me to
> >>use a windowing function in unapi.holdings_xml to rank the results
> >>based
> >>on whether the owning library matches the preferred location, and then
> >>order by rank, library name, and call number label.
> 
> If I'm understanding this correctly, then, if my preferred location owns 15
> copies of a title, the latter method will allow paging after the first 10
> copies while the more simplistic approach may not be able to handle that as
> well? Is that correct?

Not quite. 

In a working scenario for the simplistic solution, let's say there are 5
copies total for a given record in the current search scope. If you're
showing 5 copies per page of results, ordered strictly by library name
on the database side, then the Template Toolkit layer could iterate
through those copies to find any that match the preferred library and
push those copies to the front of the display list. There's no risk that
any of the matching copies would be in the second or subsequent pages of
results because there is only one page of results.

But for a simple non-working example, let's say there are 10 copies
total for a given record in the current search scope: 5 copies are at
library "AAAA" and the other 5 are at library "ZZZZ". If you're showing
5 copies per page of results, ordered strictly by library name on the
database side, then all 5 copies on the first page of results are going
to be from library "AAAA".  There's nothing that the Template Toolkit
layer of code can do if the user's preferred library is "ZZZZ"; the
first page of results will be all "AAAA" because that's all that is
available to Template Toolkit. So the right solution seems to be to
implement a windowing function that can rank by preferred library (if
passed in).

(/me realizes in passing that the CGI param "loc" suggests "location",
which could be conflated with "copy location" - maybe "lib" would be a
better choice...)