[Koha] Zebra rebuild frequency

[Paul A]

At 04:20 PM 11/14/2014 +0000, Tomas Cohen Arazi wrote:
>Paul, I'm sorry you suffered that on your Koha, but I've never seen it. I'm
>only aware of a situation that could trigger that on NORMARC (recently
>fixed) using DOM indexing.
>[snip]
> > > > 3.8.5 (production) and from my test notes 3.12.various and 3.14.2
> > > required a
> > > > complete biblio re-index after deleting a biblio record.   Has this
> > been
> > > > fixed?
> > >
> > > I don't think that was ever true. [snip]

It is true on our production box (and its backup; sandbox in other use) 
Koha: 3.08.05.000 on Linux 3.2.0-31-generic (12.04LTS), Perl version: 
5.014002, MySQL version: mysql 5.5.24,
Apache version: 2.2.22, Zebra: 2.0.44

Pls see 
<http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=kent+beyond+reef>, 
two biblios for Kent, "Beyond the reef": one is good, the other has been 
deleted, gives a 404 on the OPAC page, but will not go away from Zebra by 
cron job alone (it will go away next time I CLI re-index.) I have a feeling 
that when zebra says "incremental" it means just that -- adding new data, 
but not deleting what has gone from MySQL.

Slightly different case, 
<http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=steele+worcester> 
-- this was produced by "overwriting" an existing biblio (old, incomplete) 
with a new Z39.50, and adding an item -- it's the same biblio, but the 
"dead" instance will not disappear until I re-index.

This is a further example of the (for us) need to CLI re-index as the 
cronjob does not handle it.

Best -- Paul

---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://NavalMarineArchive.com> and <http://UltraMarine.ca>