OPAC numeric search's call number search bug with LC call numbers

[Yamil]

This bug has been occurring since we moved to Eg in version 2.2, and we are now in version 2.6.2.

I found an issue with LC call number searching when doing call number (shelf browser search) under the OPAC's numeric search page.

In the OPAC, go to: Advanced Search > Numeric Search > Field: Call NUmber (Shelf Browser)

EXAMPLE 1) if you do a (LC) call number search for in our system (EG 2.6.2) for "M163 (without quotes). The search results will take you to the M1630 area of our shelf browse.

http://catalog.berklee.edu/eg/opac/cnbrowse?cn=M163&locg=2

The results on our system look something like this within the shelf browser interface…

(row 1)
M1629 .A517 1990

M1629 .C2

M1629.3.A1 S7 1999

(row 2)
M1629.3.C5 N5 F8

M1630.18.M67B67 2012 (this is the "pivot" aka the best match in these results)

M1637.A7 G373

(row 3)

M1678 .M45 2001

M1687.A7 G37 v.1

M1687.A7 G37 v. 2

The search should have taken you to the M163 area of our call number (shelf) browse, and not the M1630 section. We should be taken to a pivot somewhere in between M15x and M17x, that would look similar to the following in our system…

(row 1)
M146.S22 S5 2005

M146.S763 Z9

M146.W43 R43 1980

(row 2)
M146.W54 A4 2009
M175.A4 D58 1999 (this is the "pivot" aka the best match in these results)
M175.A4 R38 1937

(row 3)

M175.A4 S37 2007

M175.A4 V64

M175.X6 A25 1987

EXAMPLE 2) In the case above the current code seems to get confused because the search on "M163" has a match on an existing item we have with call number "M1630." Though that should not matter. If we search for "Z1250," we are sent to the "Z105" area of the shelf browser, instead of the "Z1250"

http://catalog.berklee.edu/eg/opac/cnbrowse?cn=Z1250&locg=2

(row 1)
Z Ca

Z7.S639 Jo 1992

Z105 .C58 2007

(row 2)

Z 253 .U69 2010

Z283 .P37 1991 (this is the "pivot" aka the best match in these results)

Z285.5 .H63 1985

(row 3)

Z286.S37 M7 1992

Z642 .V35 2001

Z649.F35 B7 1998

The search for "Z1250" should roughly end up around here…

(row 1)
Z710 .M23 2005

Z722.5 .C351 1990

Z733.B751 W53 1977

(row 2)
Z1035.9 .P38 2003
Z1037.A1 N63 2003 (this is the "pivot" aka the best match in these results)

Z5784.A27 H66 2007

(row 3)
Z5814.U7 M46 1988

Z5956.A47 S68 1990

Z5984.U5 H32 v. 1

Here is some code that Dan Wells created to to fix this issue, though I have not been able to test it yet:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=3fce800c07fbfaaa3e848dc56ae1a8dbec54cf2f

[Kathy Lussier (klussier)]

I loaded this branch on the server at http://mlnc3.mvlcstaff.org/eg/opac. When I try to do a call number search, I'm getting an Internal Server error. I don't see any errors in the Apache error logs. I see the following in the osrfsys log:

[2014-11-10 16:33:29] open-ils.supercat [INFO:28808:Transport.pm:163:14156541722882220] Message processing duration: 0.026
[2014-11-10 16:33:29] /usr/sbin/apache2 [ERR :28822:EX.pm:66:14156541722882220] Exception: OpenSRF::EX::ERROR 2014-11-10T16:33:29 OpenSRF::AppRequest /usr/local/share/perl/5.18.2/OpenSRF/AppSession.pm:1086 System ERROR: Exception: OpenSRF::DomainObject::oilsMethodException 2014-11-10T16:33:29 OpenSRF::AppRequest /usr/local/share/perl/5.18.2/OpenSRF/AppSession.pm:1086 <500> *** Call to [open-ils.supercat.call_number.browse] failed for session [1415655209.2168515733.1427570717], thread trace [1]:
Exception: OpenSRF::EX::ERROR 2014-11-10T16:33:29 OpenSRF::Application /usr/local/share/perl/5.18.2/OpenSRF/Application.pm:233 System ERROR: Exception: OpenSRF::DomainObject::oilsMethodException 2014-11-10T16:33:29 OpenSRF::AppRequest /usr/local/share/perl/5.18.2/OpenSRF/AppSession.pm:1086 <500> Severe query error -- see error log for more details

[Dan Wells (dbw2)]

Can you look in your PostgreSQL log and report the query error you find there when triggering this? My best guess is there is something about your call number normalizer config which the code doesn't like. Thanks!

[Kathy Lussier (klussier)]

We aren't seeing anything in the PosgreSQL log.

I'm just adding a note that the internal server error only appears when the call number search is scoped to the consortium. It appears to work as expected when scoped to a system or branch. I'll need to add some records with nearby call numbers to be sure that it's working there.

Also, there are no special call number normalizer configs. This is a clean master system using the Concerto data.

[Dan Wells (dbw2)]

OK, I see what's happening now. This is a small incompatibility introduced by bug #1373693 and missed in the rebase (no direct conflict).

I'll push the fix shortly.

[Dan Wells (dbw2)]

Ok, new branch now at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1389403_cn_normalizer_detection

working/user/dbwells/lp1389403_cn_normalizer_detection

Even though it is rebased again, I left the fix as a separate commit to make it simpler for any testers to see and apply manually, if they wish. It is just one line.

Thanks for testing, Kathy!

[Kathy Lussier (klussier)]

Thank you Dan!

I did a test search with M163 and M 163, and the best match was M 175 instead of 1630. I also tested a search for M 9570, which had previously been landing in the M 957's, and the best match is now at the end of the M's as expected.

My sign-off branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1389403-cn_normalizer_detection

[Yamil (ysuarez)]

Can this patch be loaded on a 2.6 system (that is what I am running)?

Can this patch be backported to EG 2.6 since it is a bug?

[Dan Wells (dbw2)]

I have targeted this bug at 2.6.5. I consider it a bug fix, and we've been running it on our 2.6 system with no ill effects.

[Ben Shum (bshum)]

Picked Kathy's signoff to master and backported to rel_2_7 and rel_2_6. Thanks all!

[Ben Shum (bshum)]

Gah, missed part of the commits for this fix. Pushed to rel_2_7 and rel_2_6 and they will be released as part of the next maintenance release.