[Koha-bugs] [Bug 8837] New: Dewey cn_sort inaccurate

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

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

          Priority: P5 - low
 Change sponsored?: ---
            Bug ID: 8837
                CC: m.de.rooy at rijksmuseum.nl
          Assignee: gmcharlt at gmail.com
           Summary: Dewey cn_sort inaccurate
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: joy at bywatersolutions.com
          Hardware: All
            Status: NEW
           Version: rel_3_8
         Component: Cataloging
           Product: Koha

The items.cn_sort value created by the Dewey.pm does not create accurate
sorting (cn_sort) values.

Example 1:  Three similar callnumbers do not sort the same way .  Suggested fix
is to replace / with spaces.  (note: if any token[$i] consists of only one
space when sort routine progresses it should be disregarded/removed)
+--------------------------+--------------------------------+
| itemcallnumber           | cn_sort                        |
+--------------------------+--------------------------------+
| 971/P23w/v.1-2/pt.8      | 971P23WV_000000000000000_12PT_ |
| 971.01/P23w/v.1-2/pt.6-7 | 971_000000000000000_01P23WV_12 |
| 971.01/P23w/v.1-2/pt.7   | 971_01P23WV_12PT_7000000000000 |
+--------------------------+--------------------------------+

That would improve the cn_sort values:
Manually replaced '/' with spaces in items.itemcallnumber to illustrate that
process.
+--------------------------+--------------------------------+
| itemcallnumber           | cn_sort                        |
+--------------------------+--------------------------------+
| 971.01 P23w v.1-2 pt.6-7 | 971_010000000000000_P23W_V_12_ |
| 971.01 P23w v.1-2 pt.7   | 971_010000000000000_P23W_V_12_ |
| 971 P23w v.1-2 pt.8      | 971_P23W_V_12_PT_8000000000000 |
+--------------------------+--------------------------------+

However, the sort routine will adjust the second 'token' it finds that is all
digit.  In the above case it is in the last callnumber (the 8) which is padded.
 A better option would be to only adjust the only adjust the second 'token' if
it is the second token.  Further if there are two token and the second token is
not $token[2] then pad the first token with _zeros

An ideal result would be:
+--------------------------+--------------------------------+
| itemcallnumber           | cn_sort                        |
+--------------------------+--------------------------------+
| 971 P23w v.1-2 pt.8      | 971_000000000000000_P23W_V_12_ |
| 971.01 P23w v.1-2 pt.6-7 | 971_010000000000000_P23W_V_12_ |
| 971.01 P23w v.1-2 pt.7   | 971_010000000000000_P23W_V_12_ |
+--------------------------+--------------------------------+

note: 30 character limit does chop the rest of the cn_sort. Without an update
to the database, this will be 'collateral damage'.

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