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