 |
 |
Ross, What is your Fancy Pants thing doing? Is your Ruby on Rails interface actually querying GIL's Oracle backend or is it a screen scrape via BBID (which is what Nathan said he did). http://dilettantes.code4lib.org/2006/12/21/nice-threads/ BTW, nice little hack. I was impressed with using Greasemonkey to simulate what you ultimately want to be built into the catalog. Tom On 1/17/07, Ross Singer <[log in to unmask]> wrote: > > Nathan, > > I don't think that will scale to showing status information for a result > set. > > I think a compromise needs to be reached with your Systems folks. > Maybe they could review the queries? > > After all, hitting Oracle directly is more efficient than any single > part of Voyager. > > -Ross. > > On 1/17/07, Nathan Vack <[log in to unmask]> wrote: > > 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 > > > > > -- Tom