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.
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
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?
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
This was solved by Bug 6492