On Tue, Aug 24, 2010 at 2:02 PM, MJ Ray <[email protected]> wrote: > Chris Cormack wrote: >> On 20 August 2010 09:39, Michael Hafen <[email protected]> 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+ _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
