| Summary: | biblio records update fails when updating multiple authorities linked with the same biblio | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Janusz Kaczmarek <januszop> |
| Component: | MARC Authority data support | Assignee: | Janusz Kaczmarek <januszop> |
| Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
| Severity: | normal | ||
| Priority: | P3 | CC: | jcamins, koha.sekjal, paul.poulain, stephane.delaune |
| Version: | 3.6 | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: |
Proposed patch
A refreshed version of the patch Bug 5657: Changes made to sub merge to eliminate errors occuring when updating bibio records in batch (after updating multiple authority records) |
||
This bug is mentioned in: Bug 5657 Changes made to sub merge to eliminate errors occuring when updating bibio records in batch (after updating multiple authority records) http://lists.koha-community.org/pipermail/koha-patches/2011-January/013701.html This patch conflicts with patch bug 5943. It just changes the sub merge C4::AuthoritiesMarc::merge which is only used by function C4::AuthoritiesMarc::ModAuthority if (C4::Context->preference('MergeAuthoritiesOnUpdate') ). This syspref does not exist by default. So it makes me doubt the relevance of this patch I am wondering--and how then about the merge_authority.pl script (it makes use of C4::AuthoritiesMarc::merge), which in turn should be executed (as cron job for example, if I understand well) if MergeAuthoritiesOnUpdate is off (which is the default)...? Applying: Changes made to sub merge to eliminate errors occuring when updating bibio records in batch (after updating multiple authority records) error: patch failed: C4/AuthoritiesMarc.pm:1299 error: C4/AuthoritiesMarc.pm: patch does not apply fatal: sha1 information is lacking or useless (C4/AuthoritiesMarc.pm). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Created attachment 7415 [details] [review] A refreshed version of the patch A refreshed version of the patch (should apply smoothly to 3.7.x master). Created attachment 8145 [details] [review] Bug 5657: Changes made to sub merge to eliminate errors occuring when updating bibio records in batch (after updating multiple authority records) Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Looks like this patch changes a direct passage of the Zebra MARC record result to a re-fetch, based on the biblionumber. This should help eliminate conditions where the details of a record change mid-stream, at the cost of some processing time. Change looks good, marking as Passed QA. This patch result in a loss of performance, but it's much better than losing things ;-) (I haven't numbers, but instead of just retrieving from zebra, there are additional SQL queries to retrieve the data, so it can only be slower) This bug will be included in the Koha 3.6.5 release. |
Created attachment 3022 [details] Proposed patch There is a following issue in authority support, when updating multiple authorities and then updating biblio records in batch (in Zebra mode). If both happens: 1) two authorities linked with the same bibliographic record are updated; 2) and then between two subsequent calls of the merge function (i.e. by merge_authority.pl script) the zebra database will not be updated, then after the second call of the merge function the field controlled by the first authority will return to its original state. This is because in the merge functions (in Zebra mode) the bibliographic records to be updated are collected from zebra database and not from sql database, which contains the fresh updated version of records. Imagine the following scenario: there are two authors of a work described by record R, say A and B. A and B have their authority records. We are updating both authority records and the authors become now A1 and B1 (in authorities). We have Zebra indexes and dontmerge syspref set to 1. Now we run merge_authority.pl script in batch mode. After the first run of the while loop author A in R becomes A1 (and R becomes R1) and the updated record is stored (by ModBiblio called from merge) only in sql database. So far so good. But then, in the second run, merge functions selects records for update from zebra database so, if zebra queue processing was not fast enough or was switched off at the moment, what will be updated now is R from zebra database (and not R1 from sql database). And therefore after the second run we get R2, where the second author is B1, but first is still A. Attached is a simple workaround. Comments are welcome.