[VuFind-Tech] call number browse and debugging position in index

[Tod O. <to...@uc...>]

vufind-tech,

I’m running into an odd problem with the browse handler. With a local normalizing class (which passes my unit tests for sort order), a call # browse for “k” puts me at the top of the Ks:

  https://magma.lib.uchicago.edu/vufind/alphabrowse/results?from=k&source=lcc

But a search for “xxk” (a local variation) puts the search after the XXKs:

  https://magma.lib.uchicago.edu/vufind/alphabrowse/results?from=xxk&source=lcc

>From my unit tests on the underlying code this makes no sense, so I’m trying to debug the problem at the browse-handler level. But I’m a little uncertain how to get a good look at what’s going on.

I do try looking into the SQLite db directly, but no joy from the command line. All of my queries put me at the beginning of the table:

sqlite> select rowid from headings where key >= "K" order by rowid limit 1;
1

sqlite> select * from headings where key >= 'KB' order by rowid limit 5;
5553 0156 |5553 0156
6644 3462 |6644 3462
9110.26 1304 :214 |9110.26 1304 :214
AP  0020.000000 O0.300000 N.S. NO.000132 P.000203-000278|AP20.O3 n.s. no.132 p.203-278
ARCH0000.000000 ARCHnull|ARCH

(Yes, those are really crappy things to have in the LC call index! But the are the head of the list in my little test database.)

Anyhow, I’m looking for idea about how to debug this code, so I can figure out why the XX query is going bad. I’m kind of stuck at the moment, any suggestions for how to proceed are welcome.

-Tod