[Koha-bugs] [Bug 10462] Some optimizations in Z3950 search paving the way for enhancements

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10462

Galen Charlton <gmcharlt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Passed QA                   |Failed QA
                 CC|                            |gmcharlt at gmail.com

--- Comment #11 from Galen Charlton <gmcharlt at gmail.com> ---
This patch changes what gets returned as the LCCN.  The acronym "LCCN" is
ambiguous, unfortunately, as it can refer to LC Control Number or LC Call
Number.  The current behavior of the Z39.50 search is to return the former
(i.e., the control number or LC-assigned identification number).

Here is a diff (before and after applying the patch) of the output of a little
test script I wrote that searches LC's Z39.50 server for ISBN 9780415964845.

                  'total_pages' => 1,
                  'breeding_loop' => [
                                       {
-                                        'lccn' => '  2008005439',
-                                        'breedingid' => '91',
-                                        'date' => '2008',
-                                        'author' => undef,
+                                        'lccn' => 'PR6068.O93',
+                                        'date' => '2008.',
+                                        'breedingid' => '92',
+                                        'author' => '',
                                         'biblionumber' => undef,
                                         'edition' => '2nd ed.',
                                         'server' => 'LIBRARY OF CONGRESS',

I'm marking this as failed QA for the change in visible behavior, but this
issue speaks to a broader concern I have with this patch: why replace the call
to TransformMarcToKoha, which uses the installed default bibliographic
framework to extract strings from the MARC record, with hardcoding the tags and
subfields for each MARC flavor?

-- 
You are receiving this mail because:
You are watching all bug changes.