[Koha-bugs] [Bug 12343] TransformKohaToMarc() is adding MARC subfields in random order

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Jun 11 13:37:38 CEST 2014


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

Jonathan Druart <jonathan.druart at biblibre.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #28719|0                           |1
        is obsolete|                            |

--- Comment #6 from Jonathan Druart <jonathan.druart at biblibre.com> ---
Created attachment 28776
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28776&action=edit
Bug 12343 - TransformKohaToMarc() is adding MARC subfields in random order

TransformKohaToMarc() function in C4/Biblio.pm iterates through it's
argument - which is a hashref - using 'each'. Perl is not guaranteed
to return hash keys in any particular order (not to mention that
in more recent perl versions, explicit hash key order randomization
is to be expected).

As a consequence:
1) For biblio records added via acquisition (order from a new/empty
record, order from a suggestion), freshly created MARC biblio records
doesn't always have 260 $b and 260 $c stored in the proper order
2) Holdings data exported for zebra indexing as 952 fields may have
subfields generated in more-or-less random order. While it probably (?)
does not affect zebra indexing/searching in any significant way,
end result is prone to be somehow ugly (which can be a potential
issue e.g. for people running Z39.50 server) and is not guaranteed
to be consistent; different records - or even different items in the
same record, can have 952 subfields generated in indiscriminate order.

This patch fixes abovementioned issues via introducting explicit
sorting (by subfiled code/letter) for subfield pairs before they
are added to the MARC record.

To test:
1/ Try to confirm and reproduce both issues (use perl 5.18.1 if possible
for more randomly ordered results).
2/ Apply patch.
3/ Redo the tests; ensure that both issues are now fixed and that there
are no apparent regressions of any kind (especially regarding to 952 fields
generated for zebra [re]indexing).

Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>

Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>

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


More information about the Koha-bugs mailing list