Bugzilla – Attachment 175667 Details for
Bug 34739
Linked biblios should not be merged (updated) when changes to an authority don't change the authorized heading
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
Bug 34739: Linked biblios should not be merged (updated) when changes to an authority don't change the authorized heading
Bug-34739-Linked-biblios-should-not-be-merged-upda.patch (text/plain), 5.50 KB, created by
Roman Dolny
on 2024-12-18 19:04:46 UTC
(
hide
)
Description:
Bug 34739: Linked biblios should not be merged (updated) when changes to an authority don't change the authorized heading
Filename:
MIME Type:
Creator:
Roman Dolny
Created:
2024-12-18 19:04:46 UTC
Size:
5.50 KB
patch
obsolete
>From e2d8679bf7efc69066f7385c6a469d78552afbf5 Mon Sep 17 00:00:00 2001 >From: Janusz Kaczmarek <januszop@gmail.com> >Date: Wed, 18 Dec 2024 11:20:39 +0000 >Subject: [PATCH] Bug 34739: Linked biblios should not be merged (updated) when > changes to an authority don't change the authorized heading >MIME-Version: 1.0 >Content-Type: text/plain; charset=UTF-8 >Content-Transfer-Encoding: 8bit > >Currently, the function C4::AuthoritiesMarc::merge calls ModBiblio for >all bibliographic records linked to the modified authority record. It >could seem a just behavior but we know that this could lead to >performance problems. This is why AuthorityMergeLimit >systempreference with merge_authorities.pl was introduced (earlier: >dontmerge). > >Although this partially solves the performance problems, for >moderately large and large catalogs (500+ K) and authority records >linked with a large number of bibliographic records, performance >problems still occur, even with overnight processing with >merge_authorities.pl. This problem is particularly apparent when >updating authority records from central databases, whose modifications >are beyond our control. > >It turns out, however, that many such modifications to authority >records involve fields other than the heading field (1XX in MARC 21), >so these updates in fact do not modify bibliographic records. >However, with the current merge function, every touch on an >authority record forces a call to the ModBiblio function. The >number of relatively expensive ModBiblio calls could be >reduced by checking whether there has been an actual change in >the field associated with the authority record. > >However, with IncludeSeeFromInSearches or IncludeSeeAlsoFromInSearches >preferences enabled, the record should be refreshed in the search >engine just in case (should the 4XX, 5XX fields have changed, which we >don't know at this point). > >Test plan: >========== >1. Make sure to have CataloguingLog set to Log and > IncludeSeeFromInSearches set to Include. >2. Have a bibliographic record with an authority record linked. Open > the authority record in a separate tab, open it in the editor and > save, without modifying it. Repeat this 2-3 times. In the > bibliographic record tab open the Modification log and see a number of > entries - for each âemptyâ modification of the linked authority > record. >3. Apply the patch ; restart_all. >4. Repat p. 2. Note that there are no new entries in the log. >5. Edit the authority record again, this time putting in one of the > proper 4XX $a subfield an uncommon word (but do not touch the 1XX > field). Save the authority record. In the bibliographic record > tab control that there are no new entries in the modification log. > Make a search for the word put in 4XX field. You should get the > bibliographic record(s) linked to the edited authority record, even > though the bibliographic record itself has not been modified. >6. Edit the authority record again, this time changing the 1XX field. > Save the authority record. In the bibliographic record tab control > that there are is new entry in the modification log. > >Sponsored-by: Ignatianum University in Cracow >Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> >--- > C4/AuthoritiesMarc.pm | 27 ++++++++++++++++++++++++--- > 1 file changed, 24 insertions(+), 3 deletions(-) > >diff --git a/C4/AuthoritiesMarc.pm b/C4/AuthoritiesMarc.pm >index 4fe55cd34b..d0cec3f311 100644 >--- a/C4/AuthoritiesMarc.pm >+++ b/C4/AuthoritiesMarc.pm >@@ -1595,6 +1595,7 @@ sub merge { > while ( my $biblio = $biblios->next ) { > my $marcrecord = $biblio->metadata->record; > my $update = 0; >+ my $reindex_if_needed = 0; > foreach my $tagfield (@$tags_using_authtype) { > my $countfrom = 0; # used in strict mode to remove duplicates > foreach my $field ( $marcrecord->field($tagfield) ) { >@@ -1656,15 +1657,35 @@ sub merge { > $field_to->delete_subfield( code => '9' ); > $field_to->add_subfields( 9 => $mergeto ); > >- if ($tags_new && @$tags_new) { >+ if ( $tags_new && @$tags_new ) { > $marcrecord->delete_field($field); > append_fields_ordered( $marcrecord, $field_to ); >+ $update = 1; > } else { >- $field->replace_with($field_to); >+ >+ # If there was no real change of the linked bibliographic >+ # field, there is also no need to make ModBiblio. >+ # Only a refresh of index could be helpful in case of >+ # a change in the tracing fields >+ if ( $field->as_formatted ne $field_to->as_formatted ) { >+ $field->replace_with($field_to); >+ $update = 1; >+ } else { >+ $reindex_if_needed = 1; >+ } > } >- $update = 1; > } > } >+ if ( >+ !$update >+ && $reindex_if_needed >+ && ( C4::Context->preference('IncludeSeeFromInSearches') >+ || C4::Context->preference('IncludeSeeAlsoFromInSearches') ) >+ ) >+ { >+ my $indexer = Koha::SearchEngine::Indexer->new( { index => $Koha::SearchEngine::BIBLIOS_INDEX } ); >+ $indexer->index_records( $biblio->biblionumber, "specialUpdate", "biblioserver" ); >+ } > next if !$update; > ModBiblio( $marcrecord, $biblio->biblionumber, $biblio->frameworkcode, { disable_autolink => 1 } ); > $counteditedbiblio++; >-- >2.39.5
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
|
Splinter Review
Attachments on
bug 34739
:
175665
|
175666
| 175667 |
175668