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

[Bill Erickson]

On Mon, Dec 12, 2011 at 02:22:06PM -0500, Dan Scott wrote:
> 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.

Of course.  Let me rephrase...  Lest it go unnoticed, tpac already has
something that looks a lot like "preferred library".  Maybe we can use
it.

I didn't mean to suggest we had to stick w/ json_query.

> 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)?

I admit, passing around piles of XML (inside of JSON (inside of XML))
makes me queasy.  And the lack of fine-grained fleshing/sorting/paging
control is something we have to overcome.  My hope is the rewards will 
outweigh the cost in the long run, particularly as more Evergreen 
components use unapi.  (This is some potent reverse psychology ;)  As 
always, though, if it turns out to be a poor tool for the job, we 
should reconsider.

-b

-- 
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com 
| Equinox Software, Inc. / Your Library's Guide to Open Source