[Koha-devel] (sort of) Refactoring rebuild_zebra

[LAURENT Henri-Damien]

Le 24/08/2010 19:02, MJ Ray a écrit :
> Chris Cormack wrote:
>> On 20 August 2010 09:39, Michael Hafen <mdhafen at 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?
> 
> Hope that helps,
If I may contribute my 2 cents :
I think that rebuild zebra should be separated into two parts :
- export of biblio
- indexation
We could export biblio into a directory, always the same and then
process that with inotify.
In fact I think we need a more powerful and robust export tool.
And since zebraidx is used in rebuild zebra we could use inotify to
process that and get the logs, to tell whether the indexation went good
or bad.
Then it would not be possible to launch more than one zebraidx at once
and crash the machine.
It would be safer since we could have more little pieces of information
to index.
And we would not depend on a cronjob but on a deamon.

Drawback is that it would only run on Linux.... at the moment... Maybe
we could use jnotify...

My 2 cents.
-- 
Henri-Damien LAURENT