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
|