[pygr-notify] Issue 56 in pygr: unable to access the sequence object via a saved bound schema attribute :(

[codesite-noreply at google.com]

Comment #3 on issue 56 by jqian.ubc: unable to access the sequence object  
via a saved bound schema attribute :(
http://code.google.com/p/pygr/issues/detail?id=56

I removed the start entry from the sliceAttrDict in Chris's issue56.py as  
suggested.
  I got the following error message:
Traceback (most recent call last):
   File "issue56_nostart.py", line 36, in <module>
     orientation='seq_region_strand'))
   File "/home/qing/workspace2008/pygr/pygr/seqdb.py", line 490, in __init__
     self.get_annot_obj(k, self.sliceDB[k]) # valid annotation object?
   File "/home/qing/workspace2008/pygr/pygr/seqdb.py", line 527, in  
get_annot_obj
     start = int(self.getSliceAttr(sliceInfo,'start'))
   File "/home/qing/workspace2008/pygr/pygr/seqdb.py", line 520, in  
getSliceAttr
     return getattr(sliceInfo,attr) # GET ATTRIBUTE AS USUAL
AttributeError: 'TupleO_homo_sapiens_core_47_36i.exon' object has no  
attribute 'start'

WARNING: saving pygr.Data pending data that you forgot to save...
Remember in the future, you must issue the command pygr.Data.save() to save
your pending pygr.Data resources to your resource database(s), or  
alternatively
pygr.Data.rollback() to dump those pending data without saving them.
It is a very bad idea to rely on this automatic attempt to save your
forgotten data, because it is possible that the Python interpreter
may never call this function at exit (for details see the atexit module
docs in the Python Library Reference).

However, if I explicitly override the default itemClass (TupleO) with
seqregion.EnsemblRow, when constructing an sqlgraph.SQLTable object, then  
everything
is fine again.

exonTB = sqlgraph.SQLTable('homo_sapiens_core_47_36i.exon',
itemClass=seqregion.EnsemblRow, serverInfo=conn)

transcriptTB = sqlgraph.SQLTable('homo_sapiens_core_47_36i.transcript',
itemClass=seqregion.EnsemblRow, serverInfo=conn)

exonAnnoDB = seqdb.AnnotationDB(exonTB, sr,
                                 sliceAttrDict=dict(id='seq_region_id',
                                                    stop='seq_region_end',
                                                     
orientation='seq_region_strand'))

transcriptAnnoDB =seqdb.AnnotationDB(transcriptTB, sr,
                                      sliceAttrDict=dict(id='seq_region_id',
                                                          
stop='seq_region_end',
                                                        
orientation='seq_region_strand'))

In this case, I don't need to supply the *start* field when constructing an
Annotation object, because it has been defined in the seqregion.EnsemblRow  
class as
seq_region_start - 1, *not* seq_region_start.  Therefore, the potential  
cause of the
bug indicated in Comment 2 is not the real reason.

Note, I did check out the latest code from git before I performed all these  
tests.
Maybe something magical in the latest code killed the bug :)

qing at 1[ensembl]$ time python issue56_itemClass_nostart.py

real    0m22.228s
user    0m0.838s
sys     0m0.096s

qing at 1[ensembl]$ python -i
Python 2.5.2 (r252:60911, Nov 14 2008, 19:46:32)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygr.Data
>>> transcriptDB =  
pygr.Data.Bio.Annotation.Ensembl.homo_sapiens_core_47_36i.transcript()
>>> transcript = transcriptDB[1]
>>> exons = transcript.exons
>>> for e in exons: print e.id, e.seq_region_start
...
1 19397
2 14600
3 8131
4 7778
5 7465
6 7096
7 6721
8 6611
9 6470
10 5767
11 5659
12 4863
13 4274
>>> for e in exons: print e.id, len(e.sequence)
...
1 273
2 155
3 99
4 147
5 141
6 132
7 198
8 18
9 139
10 44
11 106
12 39
13 92
>>> for e in exons: print e.id, str(e.sequence)
...
1
GGAAAGCGGGTCAAGGCGTAGGGCTGGAGGGCAGGGGCGGGCCCTGGGCGTGGGCTGGGGGTCCTGCCCCGGGGCGCACCCCGGGCGAGGGCTGCCCGGAGGAGCCGAGGTTGGCGGACAGCTTGGCCCTGAGCTTGAGGGGAAGGCAGCGATGGGACAAAGGACGGAGGTCTAGGAAGAGGGTCTGCAGAGCAGAAAGCACGGGTAGGGGCGGCCTGACGCTCGGAAGACAACGCATGGGAGCCGTGTGCACGTCGGGAGCTCGGAGTGAGC
2
GCACCATGACTCCTGTGAGGATGCAGCACTCCCTGGCAGGTCAGACCTATGCCGTGCCCTTCATCCAGCCAGACCTGCGGCGAGAGGAGGCCGTCCAGCAGATGGCGGATGCCCTGCAGTACCTGCAGAAGGTCTCTGGAGACATCTTCAGCAGG
3
GTAGAGCAGAGCCGGAGCCAGGTGCAGGCCATTGGAGAGAAGGTCTCCTTGGCCCAGGCCAAGATTGAGAAGATCAAGGGCAGCAAGAAGGCCATCAAG
4
GTGTTCTCCAGTGCCAAGTACCCTGCTCCAGGGCGCCTGCAGGAATATGGCTCCATCTTCACGGGCGCCCAGGACCCTGGCCTGCAGAGACGCCCCCGCCACAGGATCCAGAGCAAGCACCGCCCCCTGGACGAGCGGGCCCTGCAG
5
GAGAAGCTGAAGGACTTTCCTGTGTGCGTGAGCACCAAGCCGGAGCCCGAGGACGATGCAGAAGAGGGACTTGGGGGTCTTCCCAGCAACATCAGCTCTGTCAGCTCCTTGCTGCTCTTCAACACCACCGAGAACCTGTAT
6
AAGAAGTATGTCTTCCTGGACCCCCTGGCTGGTGCTGTAACAAAGACCCATGTGATGCTGGGGGCAGAGACAGAGGAGAAGCTGTTTGATGCCCCCTTGTCCATCAGCAAGAGAGAGCAGCTGGAACAGCAG
7
GTCCCAGAGAACTACTTCTATGTGCCAGACCTGGGCCAGGTGCCTGAGATTGATGTTCCATCCTACCTGCCTGACCTGCCCGGCATTGCCAACGACCTCATGTACATTGCCGACCTGGGCCCCGGCATTGCCCCCTCTGCCCCTGGCACCATTCCAGAACTGCCCACCTTCCACACTGAGGTAGCCGAGCCTCTCAAG
8 ACCTACAAGATGGGGTac
9
acaccacccccaccgcccccaccaccacccccaGCTCCTGAGGTGCTGGCCAGTGCACCCCCACTCCCACCCTCAACCGCGGCCCCTGTAGGCCAAGGCGCCAGGCAGGACGACAGCAGCAGCAGCGCGTCTCCTTCAG
10 TCCAGGGAGCTCCCAGGGAAGTGGTTGACCCCTCCGGTGGCTGG
11
ACTCTGCTAGAGTCCATCCGCCAAGCTGGGGGCATCGGCAAGGCCAAGCTGCGCAGCATGAAGGAGCGAAAGCTGGAGAAGCAGCAGCAGAAGGAGCAGGAGCAAG
12 TGAGAGCCACGAGCCAAGGTGGGCACTTGATGTCGGATC
13
TGCTCCATGGGGGGACGGCTCCACCCAGCCTGCGCCACTGTGTTCTTAAGAGGCTTCCAGAGAAAACGGCACACCAATCAATAAAGAACTGA
>>>



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings