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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
