]> git.koha-community.org Git - koha.git/commit
Bug 12343 - TransformKohaToMarc() is adding MARC subfields in random order
authorJacek Ablewicz <abl@biblos.pk.edu.pl>
Tue, 3 Jun 2014 07:24:23 +0000 (09:24 +0200)
committerTomas Cohen Arazi <tomascohen@gmail.com>
Sun, 15 Jun 2014 14:27:20 +0000 (11:27 -0300)
commit661f9e01d64909692c98686a3117db1927f6bd20
tree92e7b7e79572d5adfe7f1726546ce49cfd7b9d24
parent6dd79171a5eced348dc1cffd231c7d368eb66508
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@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
C4/Biblio.pm