http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 --- Comment #1 from Galen Charlton <gmcharlt@gmail.com> --- Could you add the exact cronjob invocation to this bug? I tried deleting bibs in a tiny test database that's using DOM indexing, both with and without the patch for bug 9496, and the records were deleted from the Zebra index when I ran rebuild_zebra.pl -b -z or rebuild_zebra.pl -b -x -z. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 Jorge de Cardenas <jdeca@smfpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdeca@smfpl.org --- Comment #3 from Jorge de Cardenas <jdeca@smfpl.org> --- I am seeing the same issue. Example 1: delete all items run ./rebuild_zebra -b -z rerun search biblio is found with no items delete record run ./rebuild_zebra -b -z rerun search biblio with no items still shows up Example 2: delete all items and delete record run ./rebuild_zebra -b -z rerun search biblio with items will show up As a note: if "adelete" is replace with "delete" in you get "[warn] cannot delete record above (seems new)" for both cases above. The only way to correct the search results is to run ./rebuild_zebra -b -r It appears that the biblio record cannot be found by zebraidx to be removed. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 --- Comment #5 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- What version of Koha are you using, Jorge? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 Paul A <paul.a@aandc.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.a@aandc.org --- Comment #7 from Paul A <paul.a@aandc.org> --- I can confirm (3.8.5) that rebuild_zebra with the incremental option -z, the biblio deletion does not occur; a full rebuild -b (with or without -x) is fully functional but is a *necessity*. This bug is [seriously?] compounded by overwriting a biblio with a Z39.50 import. This creates a second record in Zebra (not MySQL), identical biblionumber, callnumber, intemnumber: see <http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?idx=callnum&q=GRLK-GREE-10> If a staff cataloguer is unaware of this bug and deletes the apparently incorrect (old) record, this deletes the good MySQL record. I therefore suggest upgrading this bug to "critical." -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 --- Comment #8 from Galen Charlton <gmcharlt@gmail.com> --- For those who are seeing this bug, could you paste the results of running the command zebraidx -V -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 --- Comment #10 from Galen Charlton <gmcharlt@gmail.com> --- A comparison of the Zebra config of a database experiencing this problem shows that it lacked the patch for bug 8665. In particular, the Zebra record ID must be taken (for MARC21) from the 999$c, but prior to the patch for 8665, it was taken from the 001. This also explains why I couldn't reproduce the problem myself -- I was using master. Try updating biblio-koha-indexdefs.xml and biblio-zebra-indexdefs.xml, then do a full reindex of the bibs. After that is done, I suspect that rebuild_zebra.pl -z will start removing deleted bibs from the Zebra index. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 --- Comment #12 from Melia Meggs <melia@bywatersolutions.com> --- We've got two libraries that were previously experiencing this problem on 3.8.5. We have upgraded them to 3.8.8, and both are now reporting that this problem looks to be resolved based on their testing so far. Thanks, Galen! Melia -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9511 --- Comment #14 from Paul A <paul.a@aandc.org> --- (In reply to comment #13)

3.8.10 tarball on Ubuntu 12.04.2 LTS, db imported from 3.8.5; using an incremental CRON '$KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z -x' (with or without the '-x') does not remove the deleted record; a complete rebuild_zebra.pl -b -r -v -x is required.

Illustrated example of problem: Starting point: type='BK', title='The Hudson through the years', author='Adams, Arthur G.' Before intervention, we had *three* biblios, 1 for publisher='Fordham...', two for publisher='Lind...', each biblio with a single, valid 'item.' We did the following: - Transfer (copy barcode and "attach") a 'Lind' item from one biblio to the other and delete the "empty" biblio. - Overwrite the 'Lind' biblio now containing two items with a Z39.50 biblio from LoC (DLC.) After this, we had *four* [relevant] biblios in OPAC, see <http://navalmarinearchive.com/ims/opac_hudson_before_full_rebuild.jpg>. #1 as expected, untouched, #2 gave a 404 error (the deleted biblio), #3 was the *old* biblio with both items, #4 was the desired result (Z39.50 biblio with both items.) The "incremental" user=koha CRON ($KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z) ran every minute overnight and did not correct this. Errors are redirected >> /tmp/cron_koha.log 2>&1 and no errors were reported. Running a ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x this morning instantly corrected OPAC, see <http://navalmarinearchive.com/ims/opac_hudson_after_full_rebuild.jpg>. -- You are receiving this mail because: You are watching all bug changes.