Bug 9243

Summary: Bad delete order in sub index_records in rebuild_zebra.pl
Product: Koha Reporter: Christophe Croullebois <christophe.croullebois>
Component: CatalogingAssignee: Christophe Croullebois <christophe.croullebois>
Status: CLOSED INVALID QA Contact: Marcel de Rooy <m.de.rooy>
Severity: enhancement    
Priority: P5 - low CC: fridolin.somers, m.de.rooy
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6492
GIT URL: Change sponsored?: ---
Patch complexity: Small patch Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: proposed patch

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