 |
 |
> Sure isn't elegant, but as our Real Systems Guys don't want us to > look at the production Oracle instance (performance worries), we've > had pretty good luck screen-scraping holdings and status data, once > we get a Bib ID. Ugly, but functional, and surprisingly fast. A big repercussion of hooking into the circ data via an http call to the Voyager opac is that it generates a "session" of which their are a limited number (per the Voyager/Oracle licensing) and each session that is created hangs around until it expires per the time out setting in the appropriate ini file. So to scale, you would either have to *manage* the session state on the Lucene/Solr side of things so that each user kept the same session rather than generating a new session with each search (no trivial thing) or you would have to implement some hacks on the Voyager side to keep from overwhelming the license restraints. I guess you could crank the time out down to 10 seconds or so (rather than the typical 10 minutes). This assumes that you've totally turned off public access to the Voyager opac, but who knows what unintended consequences that will have. -- Michael # Michael Doran, Systems Librarian # University of Texas at Arlington # 817-272-5326 office # 817-688-1926 cell # [log in to unmask] # http://rocky.uta.edu/doran/ ________________________________ From: Code for Libraries on behalf of Nathan Vack Sent: Wed 1/17/2007 4:50 PM To: [log in to unmask] Subject: Re: [CODE4LIB] Getting data from Voyager into XML? On Jan 17, 2007, at 2:59 PM, Bess Sadler wrote: > As long as we're on the subject, does anyone want to share strategies > for syncing circulation data? It sounds like we're all talking about > the parallel systems á la NCSU's Endeca system, which I think is a > great idea. It's the circ data that keeps nagging at me, though. Is > there an elegant way to use your fancy new faceted browser to search > against circ data w/out re-dumping the whole thing every night? Sure isn't elegant, but as our Real Systems Guys don't want us to look at the production Oracle instance (performance worries), we've had pretty good luck screen-scraping holdings and status data, once we get a Bib ID. Ugly, but functional, and surprisingly fast. Of course, spamming the OPAC with HTTP calls certainly impacts performance more than just querying the database... but I digress. In a perfect world, we'd get a trigger / stored proc on the database server when circ status changed. In a slightly less perfect world, I'd just keep a connection open to the production datbase server for all of that. -n