Bug 9243 - Bad delete order in sub index_records in rebuild_zebra.pl
Summary: Bad delete order in sub index_records in rebuild_zebra.pl
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Christophe Croullebois
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-07 14:20 UTC by Christophe Croullebois
Modified: 2014-12-07 20:02 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
proposed patch (2.39 KB, patch)
2012-12-07 14:48 UTC, Christophe Croullebois
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Croullebois 2012-12-07 14:20:52 UTC
If we have in the zebraqueue table for the same record, one line "update" and another "delete", the index_records sub in rebuild_zebra.pl treats the delete line first. 
The result is that the record still exists in zebra.
Comment 1 Christophe Croullebois 2012-12-07 14:48:27 UTC
Created attachment 13927 [details] [review]
proposed patch

to test:
make changes for a biblio record and save
delete the record
check in zebraqueue table that you have 2 lines for this record
run rebuild zebra.pl -z -b -l 50
Without the patch the record still exist for zebra
thx
Comment 2 Marcel de Rooy 2012-12-13 10:58:50 UTC
As far as I can see, this problem is already fixed in master. Your patch introduces the following problem:
Can't use an undefined value as a HASH reference at ./rebuild_zebra.pl line 422.
This has to do with the uninitialized $records_deleted.

Please note however that the routine export_marc_records_from_list gets the deleted records hash and skips these deleted records when creating the file for the update step.
This is done in the following rather obscure code:
    foreach my $record_number ( map { $_->{biblio_auth_number} }
                                grep { !$found{ $_->{biblio_auth_number} }++ }
                                @$entries ) {

I tested update and delete with and without your patch.
With your patch, the above error occurs.
Without your patch, the problem does not occur and the records are deleted from zebra. 
I suggest to close this report. Do you agree with the above explanation in mind?
Comment 3 Christophe Croullebois 2012-12-13 11:14:08 UTC
Hello,
oups, sorry done too fast.
At the beginning it comes from a patch for 3.2 and it was just ask to me to reverse the two blocks. I rebase for master when I saw that the 2 blocks were in the same order also in master, I didn't look further...
So you'r right M. de Rooy, yes please close.
thx
Comment 4 Fridolin Somers 2012-12-20 13:05:09 UTC
This was solved by Bug 6492