On Tue, Aug 24, 2010 at 2:02 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Chris Cormack wrote:
On 20 August 2010 09:39, Michael Hafen <mdhafen@tech.washk12.org> wrote:
I wonder now if we could seperate the two. So cataloging updated zebra immediately, but circulation was queued.
Would that work?
Its certainly a possibility, would involve a bit of work, since the calls are down in module level, not script level, and at that level often the code doesn't know whether it's being called as a result of circulation, or a cataloguing change, (or a branch transfer .. or whatever else i've forgotten :-))
This would be good because I sometimes get asked if Koha's index does "realtime" updating and at the moment the honest answer depends how you define "realtime". Unlike other systems, librarians can see for themselves the index update process.
But I don't know if this limits adoption, as so far no library has offered to pay the co-op to change it. ;-)
I have a slight concern about the rebuild_zebra.pl rewrite: is it perpetuating the daemon/cron competing implementations? Can we figure out one size that fits all? Maybe have one daemon running and then different ways for a cron job or librarian interface task to signal (some SIG perhaps?) that it needs to act?
I've just send a rewrite of zebraqueue daemon that does run (sort of refactoring of) rebuild_zebra as one would do with cron. I think is the right way to handle this. Avoid using cron, and configure the frequency of the update via systempreferences. I first thought of a script in bash but had some concerns about the system load as each pass would spawn a new perl process. To+