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

[Dan Scott]

On Mon, Dec 12, 2011 at 01:56:18PM -0500, Bill Erickson wrote:
> On Mon, Dec 12, 2011 at 10:24:37AM -0500, Dan Scott wrote:
> > On Mon, Dec 12, 2011 at 10:14:24AM -0500, Kathy Lussier wrote:
<snip>
> > > 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...) 
> 
> Some additional info...
> 
> TPac supports a param now called "physical_loc".  It's not exactly the
> same as a "prefered library", because it's not meant to be changed by
> the user, but it could be used as the default value for prefered 
> library (among other default org units) for OPACs within the branch
> (i.e. they have a known physical location).  This is the same value set 
> by the IP address redirector module.

Yes, I had noticed physical_loc's presence in the code but as noted
below...

> Its primary purpose thus far has been to affect copy sorting on the
> detail page.  If physical_loc is set, any copies whose circ lib matches
> will be sorted to the top in the detail page.  json_query handles the
> sorting/paging like a champ.  Unapi will certainly need some new nobs 
> to do the same thing.

One of my recent focuses has been on getting rid of the
"unapi-for-results vs.  json-query-for-record-details" distinction
because of this kind of problem where, today in master, search
results cannot sort copies by any sort of relevance to a particular
library while record details can.  Hence
https://bugs.launchpad.net/evergreen/+bug/901976 which tackles part of
the set of tricks that in-db unapi needs to learn to replace the
json_query in record details. It's silly, time-wasting, behavioural
difference-inducing, and in all likelihood bug-inducing to have two
entirely different sets of database query logic to perform what is
essentially the same operation.

We could, of course, go the opposite direction and replace in-db unapi
usage in search results with the same json_query that we're using in
record details today. But if we go that route, could we just wipe in-db
unapi from the schema (at least until something starts using it again)?