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

[Mark T. <ma...@te...>]

Hi Tod,

I don't have any wonderful ideas, but I think your test queries aren't
quite representative of what the browse handler does.  The first should
get the row to start from, and the second should fetch by ID range,
ordered by key.  So:


  # Note that we order by key, not rowid.  I think ordering by rowid
  # would always yield "1", so maybe that explains always being jumped
  # to the start.
  #
  sqlite> select rowid from headings where key >= "K" order by key limit 1

  # Then select the 5 headings starting from the rowid returned above
  #
  sqlite> select * from headings where rowid >= :rowid_from_above order
          by rowid limit 5;


I'm not sure if that helps, but maybe it will yield some further clues.

Cheers,

Mark


Tod Olson <to...@uc...> writes:

> 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

-- 
Mark Triggs
<ma...@te...>