[Koha-bugs] [Bug 12424] New: ddc sorting of call numbers truncates long Cutter parts

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

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

            Bug ID: 12424
           Summary: ddc sorting of call numbers truncates long Cutter
                    parts
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Database
          Assignee: gmcharlt at gmail.com
          Reporter: giuseppe.angilella at ct.infn.it
        QA Contact: testopia at bugs.koha-community.org

Occasionally, I need quite long Cutter parts in the itemcallnumber of specific
items, e.g.

530 F435 1996 v2p1

for part 1 (p1) of volume 2 (v2) of the 1996 edition of the Feynman's (Cutter
F435) Lectures in Physics (Dewey 530).

All substrings are essential information, as another edition (2007) exists (and
is present in my library's collection). Moreover, 1996 and 2007 cannot be
abridged to 96 and 07, respectively, as this would obviously result in a wrong
sorting.

Now, since "530" has no decimal part in this case, Dewey's class sorting
routine (C4/ClassSortRoutine/Dewey.pm) recognizes "1996" as the "second digit
group", and therefore converts it into a "15-digit long group, padded on right
with zeroes" (see documentation e.g. at
https://github.com/colinsc/koha/blob/master/C4/ClassSortRoutine/Dewey.pm ).
This results in having this item sorted at the very end of all items having an
530.* Dewey class (yet before items with 531).

I could overcome this, by attaching the year part to the proper Cutter part by
a character different from a whitespace or a decimal point, e.g.

530 F435_1996 v2p1

In this way, 1996 is not an isolated "second digit group" any longer, and
"F435_1996" is not modified by the class sorting routine.

However, the resulting cn_sort field for this item looks like:

530_000000000000000_F435_1996_

namely, the volume and part substring have been truncated by MySQL, since
items.cn_sort is only a varchar(30) subfield.

The situation would be even worse for longer Cutter strings (e.g., including
trailing letter(s) from the record's title), or with item call numbers
including copy numbers.

This behaviour could be enhanced by increasing the width of the items.cn_sort
subfield in the Koha database by a sufficient number of additional characters,
to avoid truncation of long Cutter parts.

(I am not sure how one could avoid misunderstanding the year part for the Dewey
decimal part without the inclusion of a non-splitting character, if not by
modifying Dewey.pm, which is definitely not what I am suggesting here.)

Many thanks!

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