IOError: Iterator has no database

[GoogleCodeExporter]

What steps will reproduce the problem?
In [1]: from pygr import worldbase
In [2]: msa = worldbase("Bio.MSA.UCSC.dm3_multiz15way")
In [3]: genome = worldbase("Bio.Seq.Genome.DROME.dm3")
In [4]: seq = -genome['chr3L'][10959977:10959996]
In [5]: seq
Out[5]: -chr3L[10959977:10959996]

In [6]: print seq
------> print(seq)
CATCCTGGTGACCCTGCTT

In [7]: msa[seq] 

What is the expected output? What do you see instead?
I would expect a NLMSASlice, or a KeyError if it doesn't exist. Instead, an
IOError is raised:

---------------------------------------------------------------------------
IOError                                   Traceback (most recent call
last)

/home/baldig/projects/genomics/nonsvn/output/fly/motifsearch/
2009_6_4_10_47_13_3_155_1/<ipython console> in <module>()

/home/dock/shared_libraries/lx64/pkgs/pythonsandbox/2.6.2/lib/
python2.6/site-packages/pygr-0.8.0-py2.6-linux-x86_64.egg/pygr/
cnestedlist.so in pygr.cnestedlist.NLMSA.__getitem__()

/home/dock/shared_libraries/lx64/pkgs/pythonsandbox/2.6.2/lib/
python2.6/site-packages/pygr-0.8.0-py2.6-linux-x86_64.egg/pygr/
cnestedlist.so in pygr.cnestedlist.NLMSASlice.__cinit__()

/home/dock/shared_libraries/lx64/pkgs/pythonsandbox/2.6.2/lib/
python2.6/site-packages/pygr-0.8.0-py2.6-linux-x86_64.egg/pygr/
cnestedlist.so in pygr.cnestedlist.IntervalFileDBIterator.loadAll()

/home/dock/shared_libraries/lx64/pkgs/pythonsandbox/2.6.2/lib/
python2.6/site-packages/pygr-0.8.0-py2.6-linux-x86_64.egg/pygr/
cnestedlist.so in pygr.cnestedlist.IntervalFileDBIterator.nextBlock()

IOError: Iterator has no database!  Please provide a db argument. 

Original issue reported on code.google.com by kmda...@gmail.com on 8 Jun 2009 at 10:54

[GoogleCodeExporter]

This is puzzling, since IntervalFileDBIterator.__new__() forces construction of 
the
IntervalFileDB, saved as self.db.  So how could self.db be NULL in 
self.nextBlock()?

The first step we need is to reproduce the error.  If we can reproduce it, it 
should
be easy to track down and fix.

Original comment by cjlee...@gmail.com on 8 Jun 2009 at 11:31

[GoogleCodeExporter]

I tried it with the data on the biodb server, and that interval returns an 
NLMSASlice.

I can't think what would be different with our copy of the data, since we used 
the
downloader in pygr from that server to get the genome and alignment.

Original comment by kmda...@gmail.com on 9 Jun 2009 at 12:19

[GoogleCodeExporter]

accessing the alignment over XMLRPC uses a different method than accessing 
local disk
index files.  If I understand your comment 2 above, accessing it via XMLRPC 
does not
reproduce the bug, whereas accessing it from local disk files reproduces this 
bug. 
One more question: please list the steps you followed for downloading the data 
to
your system (e.g. the easiest way would be to use download=True).

Also, for the record, what OS version, Python version, and Pygr version (commit 
ID)
did you observe the bug on?

Original comment by cjlee...@gmail.com on 9 Jun 2009 at 12:27

[GoogleCodeExporter]

$ uname -a
Linux mine-16 2.6.22-gentoo-r19 #2 SMP Thu Jul 31 13:25:05 PDT 2008 x86_64 
Intel(R)
Xeon(R) CPU E5450 @ 3.00GHz GenuineIntel GNU/Linux

$ python --version
Python 2.6.2

The pygr version is 0.8.0.

Looking into the script that downloads the data...

Original comment by kmda...@gmail.com on 9 Jun 2009 at 12:48

[GoogleCodeExporter]

The commit id for our pygr version is 2e9e91ed759e306148f4b2c7e0aadff37762607e.

Original comment by kmda...@gmail.com on 9 Jun 2009 at 12:51

[GoogleCodeExporter]

fixed in v0.8.0.alpha2.  Get the latest code from github.  Marek will add the 
test for this 
bug to the megatests, since the test requires a very large dataset that is not 
included as 
part of the regular Pygr package.

Original comment by cjlee...@gmail.com on 13 Jun 2009 at 12:15

• Changed state: FixedNeedsReview
• Added labels: Milestone-Release0.8

[GoogleCodeExporter]

We have got a megatest for that now, which since the changes made by Chris were 
committed, passes. Closing the issue.

Original comment by mare...@gmail.com on 25 Jun 2009 at 1:24

• Changed state: Closed
• Added labels: reviewby-marecki