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.
