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

[Dan Scott]

On Mon, Dec 12, 2011 at 04:46:24PM -0500, Bill Erickson wrote:
> 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:
<snip>
> > > 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.

Right, sorry. I put a solid day of development into the unapi direction
and am undoubtedly overly sensitive thinking that it might be wasted
effort. But it might be! So it goes.
 
> > 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.

I gave the same sort of data-elements->XML(JSON(XML))->data-elements
description with a bit of a nervous laugh when describing in-db unapi
last week at the Conifer TPAC dev session. That said, I had assumed that
it was the anointed future; if that's up for debate, then I'm willing to
withdraw the "cut record details over to unapi" branch and focus on the
"one configurable json_query to rule them all" approach - or possibly a
better approach.

I do find the process of trying to translate what should be
straightforward SQL into a JSON query language that only our project
uses a little irksome - even with Scott McKellar's excellent
documentation - and I worry that that's just another barrier for
potential contributors. Perhaps IDL views would be the way to go, given
that this is all read-only?

One painful path or another, I just want to reach the promised land
without wasting too much time going down the wrong road.

I'm delighted that we're actually discussing development directions
(strangely on the -general list, but I'll take communication where I can
get it)! Thanks Bill.