[Bug 6789] New: Biblios with many items can result in broken search results links
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Bug #: 6789 Summary: Biblios with many items can result in broken search results links Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt@gmail.com ReportedBy: ian.walls@bywatersolutions.com QAContact: koha-bugs@lists.koha-community.org Blocks: 2453 If a title has enough item record information to push it's MARCXML record size past 1MB, any information beyond that will be ignored. The record will be indexed, but the 999$c, which contains the biblionumber and is by its numerical nature the last field in the record, could be lost, and thus the link in the search results will be broken (no biblionumber filled in, so 404 error) The solution, ideally, would be to fix Net::Z3950::ZOOM to allow for the specification of a larger maximum record size, but that's impractical at this time. Koha can be altered to put all the 952 information AFTER the 999, practically guaranteeing that the biblionumber will be in the first 1MB worth of the MARCXML. If a few items records are lost to the indexer, that's unfortunate, but bearable. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Ian Walls <ian.walls@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|gmcharlt@gmail.com |ian.walls@bywatersolutions. | |com -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 --- Comment #1 from Ian Walls <ian.walls@bywatersolutions.com> 2011-09-30 14:34:38 UTC --- Created attachment 5662 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5662 Proposed Patch See commit message... lots of details there. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Ian Walls <ian.walls@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 |PATCH-Sent Patch Status|--- |Needs Signoff --- Comment #2 from Ian Walls <ian.walls@bywatersolutions.com> 2011-09-30 14:46:06 UTC --- Example record (cannot attach due to current attachment size limits): http://bywatersolutions.com/wp-content/uploads/2011/09/bug6789-test.xml_.txt Had to rename the extension to make the website happy -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 D Ruth Bavousett <ruth@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5662|0 |1 is obsolete| | --- Comment #3 from D Ruth Bavousett <ruth@bywatersolutions.com> 2011-10-03 15:09:27 UTC --- Created attachment 5679 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5679 Signed-off patch -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 D Ruth Bavousett <ruth@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ruth@bywatersolutions.com Patch Status|Needs Signoff |Signed Off --- Comment #4 from D Ruth Bavousett <ruth@bywatersolutions.com> 2011-10-03 15:10:30 UTC --- Ian's solution here works like a charm! Tested with a real-world known-broken instance of this, and it's now working. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5679|0 |1 is obsolete| | --- Comment #5 from Paul Poulain <paul.poulain@biblibre.com> 2011-10-14 09:59:11 UTC --- Created attachment 5886 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5886 Bug 6789: biblios with many items can result in broken search results link This patch fixes an issue whereby biblios with many items (often > 500) would index, but not the biblionumber itself, resulting in search results with a) inaccurate item counts and b) no biblionumber to use in the link to the details page. This is due to Net::Z3950::ZOOM not providing a mechanism for specifying different connection attributes; the maximumRecordSize ZOOM connection attribute, if not specified, defaults to 1MB, which is less than the size of a MARC record with many, many 952 fields. Since it is unlikely we can fix Net::Z3950::ZOOM in a timely fashion, this patch aims to build a workaround on the Koha end. This patch changes EmbedItemsInMarcBiblio to use append_fields instead of insert_ordered_fields, so the 999$c will come before the item records. It's VERY unlikely we will encounter more than 1MB of biblio-level MARC content, as this would break the ISO-2709 standard by a large factor. To this end, it also moves the fix_biblio_ids portion of get_corrected_marc_record out of rebuild_zebra.pl, and makes it a part of GetMarcBiblio (right before EmbedItemsInMarcBiblio, so the 952s still come last). fix_biblio_ids is kept as a subroutine for the deletion portion of rebuild_zebra.pl, which still uses it. It also uses the subroutine parameter in GetMarcBiblio to do the EmbedItemsInMarcBiblio action, rather than having rebuild_zebra.pl perform it on the itemless record returned from GetMarcBiblio. Simpler and cleaner that way. To verify bug issue: 1. Find a biblio with over 700 items (or enough that the resulting MARCXML is greater than 1MB) 2. search for this biblio (in a search that would return multiple results, not just this title). You should get the title in the results list 3. attempt to click the link to this biblio's details page; the biblionumber should be blank, leading to a 404 To test solution: 1. Apply patch 2. modify the biblio slightly (click the 005 for example) and save OR manually add the biblio to zebraqueue for reindexing 3. after rebuild_zebra.pl -z -b -x runs, use the same search as above. The title should still appear. 4. click the link, and find yourself on the biblio detail page as desired Signed-off-by: D Ruth Bavousett <ruth@bywatersolutions.com> Signed-off-by: Paul Poulain <paul.poulain@biblibre.com> -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.poulain@biblibre.com Patch Status|Signed Off |Passed QA --- Comment #6 from Paul Poulain <paul.poulain@biblibre.com> 2011-10-14 10:07:03 UTC --- QA comment : 1- full test plan 2- change made in the core of the code but only a few lines, no side-effect I can see, except a light loss of performance caused by the _koha_marc_update_bib_ids call in GetMarcBiblio 3- MARC-independant, so works in UNIMARC as well (note in UNIMARC, the biblionumber is in 001, so the insert_ordered was not a problem) 4- Moving fix_biblio_ids into GetMarcBiblio is a good idea, and should/could be done for authorities as well : move the fix_authority_id into GetAuthority sub as well marked passed QA as the last comment is small compared to the problem this patch fixes. I suggest keeping the bug open until a fix is provided for my point 4 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 --- Comment #7 from Ian Walls <ian.walls@bywatersolutions.com> 2011-10-14 12:29:19 UTC --- Paul, Thanks for the QA! I was very uncomfortable pushing this as a ByWater-only venture, so having an independent analysis from another community member (and one who can speak to UNIMARC support at that) eases my mind muchly. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz Patch Status|Passed QA |Patch Pushed --- Comment #8 from Chris Cormack <chris@bigballofwax.co.nz> 2011-10-15 00:48:00 UTC --- Pushed please test. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6789 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- This appears to be fixed. Closing. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org