[Bioperl-l] using nfreeze instead of freeze in Bio::SeqFeature::Store

Cook, Malcolm MEC at stowers-institute.org
Thu Oct 5 15:18:08 EDT 2006



Yes, there is overhead (c.f. perldoc Storable)

    "When writing in network order, all fields are written
    out as standard lengths, which allows full interworking, but takes
    longer to read and write)"

And, I suppose there is also risk of loosing precision in using network
order:

    You can also store data in network order to allow easy sharing
across
    multiple platforms, or when storing on a socket known to be remotely
    connected. The routines to call have an initial "n" prefix for
    *network*, as in "nstore" and "nstore_fd". At retrieval time, your
data
    will be correctly restored so you don't have to know whether you're
    restoring from native or network ordered data. Double values are
stored
    stringified to ensure portability as well, at the slight risk of
loosing
    some precision in the last decimals.

So, I agree, it should be configuration option, perhaps defaulting to
using network order.

However, given the factoring of ../Bio/DB/SeqFeature/Store.pm I'm not
sure how to best make it a configuration option since the two provided
serializers don't share a common interface.  Possibly something like:

=head1 Methods for Connecting and Initializating a Database

=head2 new

 Title   : new
 Usage   : $db = Bio::DB::SeqFeature::Store->new(@options)
 Function: connect to a database
 Returns : A descendent of Bio::DB::Seqfeature::Store
 Args    : several - see below
 Status  : public

This class method creates a new database connection. The following
-name=E<gt>$value arguments are
accepted:http://iowg.brcdevel.org/gff3.html#a_fasta

 Name               Value
 ----               -----

 -adaptor           The name of the Adaptor class (default DBI::mysql)

 -serializer        The name of the serializer class (default Storable)

 -network_order     Strive to 'preserve network order' (if the
serializer implements it.  
		        Currently, only Storable.pm does, and this will
cause it to use nfreeze 
                    instead of freeze.  (default 1)

 -index_subfeatures Whether or not to make subfeatures searchable
                    (default true)

 -cache             Activate LRU caching feature -- size of cache

 -compress          Compresses features before storing them in database
                    using Compress::Zlib





Malcolm Cook
Database Applications Manager - Bioinformatics
Stowers Institute for Medical Research - Kansas City, Missouri
  

> -----Original Message-----
> From: Lincoln Stein [mailto:lincoln.stein at gmail.com] 
> Sent: Thursday, October 05, 2006 1:43 PM
> To: Cook, Malcolm
> Cc: lstein at cshl.org; bioperl-l
> Subject: Re: using nfreeze instead of freeze in Bio::SeqFeature::Store
> 
> I think it's fine unless there is a significant performance hit, in
> which case the change should be made into a configuration option. Do
> you know if there is any overhead on doing this?
> 
> Lincoln
> 
> On 10/5/06, Cook, Malcolm <MEC at stowers-institute.org> wrote:
> > Lincoln,
> >
> > I committed a change to Bio::SeqFeature::Store to use 
> nfreeze instead of
> > freeze which should allow SeqFeature objects to survive database
> > freeze/thaw cycles across architectures.
> >
> > I hope I was not presumptuous or in error in doing this....
> >
> > Regards,
> >
> > Malcolm Cook
> > Database Applications Manager - Bioinformatics
> > Stowers Institute for Medical Research - Kansas City, Missouri
> >
> >
> 
> 
> -- 
> Lincoln D. Stein
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724
> (516) 367-8380 (voice)
> (516) 367-8389 (fax)
> FOR URGENT MESSAGES & SCHEDULING,
> PLEASE CONTACT MY ASSISTANT,
> SANDRA MICHELSEN, AT michelse at cshl.edu
> 



More information about the Bioperl-l mailing list