Problems with subentries

Tim Cutts timc at chiark.greenend.org.uk
Mon Nov 29 07:17:28 EST 1999


In article <fVh*uF6do at news.chiark.greenend.org.uk>,
Tim Cutts  <timc at chiark.greenend.org.uk> wrote:
>I have now fixed SRS 5.1 so it *does* work.  It's a relatively simple
>set of patches to $SRSSOU/library.c.  The alternative query form still
>doesn't work quite right, but I'm working on that, and will submit the
>complete set of patches to this newsgroup when I'm done.  wgetz is quite
>a lot harder to debug, because it's a CGI program.  I'm having to write
>a test C program which incorporates some of wgetz' functionality to test
>with...

Hmm.  Looks like my initial optimism was somewhat misplace.  I got as
far as convincing SRS to build indices for the second type of subentry,
and to display the details with getz -info, but fetching the results of
the query was extremely hard; I found a number of bits of code which
assumed there was only one subentry database.  Take for example,
LibGetSubEntryName, which has the code:

  subLib = LibIs (lib, "subentries") ? lib : LibGetSubEntryLib (lib, 0);

and LibGetSubEntryLib itself, which despite taking a parameter for the
subEntry number, ignores it:

SLBo *LibGetSubEntryLib (SLBo *lib, Int4 subEntryN)
{
  return lib->subEntries[0];
}
  
Making the obvious changes here causes getz to crash in a major way, and
I got this down to IdSplit() filling in the wrong number (or at least,
not what I expected) in the subentry_n field.  This pointed to detailed
involvement in the structure of the indexes and $IdType objects.  At
this point I conceded defeat due to the lack of documentation and source
code comments.

Tim.






More information about the Bio-srs mailing list