Bug 29268 - Query used in Koha::Biblio->get_marc_host is incorrect
Summary: Query used in Koha::Biblio->get_marc_host is incorrect
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on: 20310
Blocks: 27507
  Show dependency treegraph
 
Reported: 2021-10-19 10:52 UTC by Martin Renvoize
Modified: 2023-03-28 13:56 UTC (History)
5 users (show)

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


Attachments
Bug 29268: Correct cni handling for get_marc_host (9.67 KB, patch)
2021-11-12 16:45 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 29268: Correct cni handling for get_marc_host (9.20 KB, patch)
2021-11-12 16:48 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2021-10-19 10:52:56 UTC
After digging through this some more in relation to bug 27507 and bug 11175 I have come to the conclusion that I think the searches performed by get_marc_host are too simplistic/incorrect.

First of all, both the 773 field and $w subfield are repeatable.. so we need to iterate for subfields as well as the field.

Secondly, I don't think the search for (RCI)CN is correct.. this is what would appear in the 773 of the child, not how the 001 would be constructed in the host.

What I believe we really need to do is as follows:

1. Iterate through 773 fields.
2. Iterate through subfield w's and looks for one of the following:
1a. (RCI)Controlnumber where the RCI matches the OrgCode syspref
1b. Fully numeric Controlnumber
3. Once we've found the form we're expecting from above iterations (1a in preference to 1b if both exist) jump out of the loops.
3. Produce the search string 'control-number=Controlnumber' for 1b. or `control-number=Controlnumber AND rci=RCI` if 1a is found.  It may also be helpful to add the `OR control-number=Controlnumber` search to 1a to account for cases where OrgCode was added to new children but was is missing from the host?
Comment 1 Marcel de Rooy 2021-10-19 11:22:41 UTC
(In reply to Martin Renvoize from comment #0)

Thx for digging :)

> First of all, both the 773 field and $w subfield are repeatable.. so we need
> to iterate for subfields as well as the field.

That would not be too hard. Rearrange in a loop:
        my $w = $f->subfield('w') or next;
        if( $w =~ /^\($orgcode\)\s*(\d+)/i or $w =~ /^\d+/ ) {

> Secondly, I don't think the search for (RCI)CN is correct.. this is what
> would appear in the 773 of the child, not how the 001 would be constructed
> in the host.

Not sure if you are right here.
There are two tries in the code:
$engine->simple_search_compat( 'Control-number='.$rcn, 0,1 );
We try with $rcn being a number only and $rcn including the orgcode too.

> It may also be helpful to add the `OR control-number=Controlnumber` search to 
> 1a to account for cases where OrgCode was added to new children but was is 
> missing from the host?

What you mean, is what the code already does?
Comment 2 Martin Renvoize 2021-11-12 16:45:14 UTC Comment hidden (obsolete)
Comment 3 Martin Renvoize 2021-11-12 16:48:45 UTC
Created attachment 127591 [details] [review]
Bug 29268: Correct cni handling for get_marc_host

This patch adds a new method for fetching an ordered list of search
queries that can then be used to fetch a records host biblio.
Comment 4 Martin Renvoize 2021-11-12 16:53:40 UTC
It took some leaps to work through this one... the host_record.t tests is failing for one case, but I'm not sure I understand the logic of what it's testing.

In this change, we iterate through all 773 fields and their corresponding `w` subfields.  We build an array of search options from this in order of most specific to least specific (our cni followed by any cni followed by just cn) searches.. we then execute these searches in order until we find one that has just a singular search match at which point we jump out of the loop and continue as we did before.
Comment 5 Magnus Enger 2022-11-11 07:51:09 UTC
Is there a test plan for this, or is it just a question of running the affected tests?
Comment 6 Magnus Enger 2023-03-28 13:56:29 UTC
$ git bz apply 29268

Bug 29268 - Query used in Koha::Biblio->get_marc_host is incorrect

127591 - Bug 29268: Correct cni handling for get_marc_host

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 29268: Correct cni handling for get_marc_host
Using index info to reconstruct a base tree...
M	Koha/Biblio.pm
M	t/db_dependent/Koha/Biblio.t
M	t/db_dependent/Koha/Biblio/host_record.t
Falling back to patching base and 3-way merge...
Auto-merging t/db_dependent/Koha/Biblio/host_record.t
Auto-merging t/db_dependent/Koha/Biblio.t
CONFLICT (content): Merge conflict in t/db_dependent/Koha/Biblio.t
Auto-merging Koha/Biblio.pm
CONFLICT (content): Merge conflict in Koha/Biblio.pm
error: Failed to merge in the changes.
Patch failed at 0001 Bug 29268: Correct cni handling for get_marc_host
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Patch left in /tmp/Bug-29268-Correct-cni-handling-for-getmarchost-k4WekE.patch