tracing the calls when importing pygr.Data

1 view
Skip to first unread message

Paul Rigor (gmail)

unread,
Apr 27, 2009, 9:33:20 PM4/27/09
to pygr...@googlegroups.com
Hi all,

I'm don't think this is covered in the wiki and/or documentation... Is there any documentation tracing the subsequent imports/instantiations/bootstrap/etc after importing pygr and/or pygr.Data?

I'm using sqlite as my database engine to store annotations and I'm trying to understand the mechanism of restoring the 'connection' between the annotations in the database and the annotation map stored locally.  Note that I'm able to build the NMLSA of the annotations against a genome.  I just can't load the resource.  

I need to know which methods call these first.  The test files aren't that informative either.  

Thanks,
Paul 

--
Paul Rigor
Graduate Student
Institute for Genomics and Bioinformatics
Donald Bren School of Information and Computer Sciences
University of California in Irvine
248 ICS2 Bldg.
+1 (760) 536 - 6767 (skype)

Christopher Lee

unread,
Apr 28, 2009, 3:21:35 PM4/28/09
to pygr...@googlegroups.com
Hi Paul,
I assume that you are trying to save a connection to a sqlite
database. I added a SQLiteServerInfo class that provides a picklable
reference to a sqlite database. You can get the code via

git checkout master
git checkout -b sqlite_serverinfo
git pull git://github.com/ctb/pygr.git sqlite_serverinfo

Here is an example of using this:

>>> from pygr import sqlgraph
>>> dbinfo = sqlgraph.SQLiteServerInfo('foo.sqlite') # same args as
to sqlite3.connect()
>>> c = dbinfo.cursor() # get a cursor
>>> c.execute('create table grr (my_id int not null primary key,
my_val varchar(32))')
<sqlite3.Cursor object at 0x15481a0>
>>> c.execute('insert into grr values (1,"bob")')
<sqlite3.Cursor object at 0x15481a0>
>>> c.execute('insert into grr values (2,"sally")')
<sqlite3.Cursor object at 0x15481a0>
>>> t = sqlgraph.SQLTable('grr', serverInfo=dbinfo) # Pygr dict-like
interface to a table
>>> len(t)
2
>>> t.keys()
[1, 2]
>>> t[1].my_val
u'bob'
>>> import pickle
>>> s = pickle.dumps(t) # test pickling the table object

WARNING: You are trying to pickle an object that has a local
file dependency stored only as a relative file path:
foo.sqlite
This is not a good idea, because anyone working in
a different directory would be unable to unpickle this object,
since it would be unable to find the file using the relative path.
To avoid this problem, SourceFileName is saving the current
working directory path so that it can translate the relative
path to an absolute path. In the future, please use absolute
paths when constructing objects that you intend to save to pygr.Data
or pickle!
>>> t2 = pickle.loads(s) # test unpickling
>>> len(t2)
2
>>> t2.keys()
[1, 2]
>>> t2.serverInfo.close() # not strictly necessary, but Windows can't
handle deletion of file that is still open...
>>> dbinfo.close()

Some attempt to answer your questions below...

-- Chris


On Apr 27, 2009, at 6:33 PM, Paul Rigor (gmail) wrote:

> Hi all,
>
> I'm don't think this is covered in the wiki and/or documentation...
> Is there any documentation tracing the subsequent imports/
> instantiations/bootstrap/etc after importing pygr and/or pygr.Data?

pygr.Data just saves data using pickle / unpickle. Anything that can
be pickled can be saved to pygr.Data. As you probably know,
unpickling automatically imports the necessary modules containing the
classes that you are unpickling. Since everything is automatic, you
don't need to import anything yourself (apart from pygr.Data)...


>
> I'm using sqlite as my database engine to store annotations and I'm
> trying to understand the mechanism of restoring the 'connection'
> between the annotations in the database and the annotation map
> stored locally. Note that I'm able to build the NMLSA of the
> annotations against a genome. I just can't load the resource.

The only difference vs. my test code above is that you would save to
pygr.Data instead of pickle:

>>> import pygr.Data
>>> t.__doc__ = 'a comment'
>>> pygr.Data.Bio.Test.MyTable = t
>>> pygr.Data.save()

Let me know if this works for you.

-- Chris

Reply all
Reply to author
Forward
0 new messages