[Bioperl-l] bioperl-db revival

[David Block]

I've got most of this done already, on MySQL.  If you want to look, I can
give you the code (it's part of WB2, which has been released free to
non-profits).  If you take parts of it, great.

You would need to clean up the namespace,  (I could be helping with this),
and the wrappers to Flybase/ensembl would be a welcome addition to my
schema.  It outputs SeqI and SeqFeatureI compliant objects.

I use an inherited AUTOLOAD, which you don't like, I know, but combined
with some fancy dynamic SQL generation, it lets you have
'entry-granularity mutability' for almost nothing in terms of coding or
maintenance.  For things to behave properly, you need a compile time 'use'
list of autoloaded subs, and a hash with the keys being the table columns.

It is all an evolved form of Damian Conway's example CD class in OOPerl,
and it has been fairly stable for about six months.  I've only added on
things that Workbench needs.

Anyone who wants a look, let me know.

-Dave





On Tue, 27 Mar 2001, Ewan Birney wrote:

> 
> 
> I have decided to revive bioperl-db for "simple" sequence storage.
> 
> [note to Hilmar/Jason - this is definitely the right place to put this now
> I have written some of the SQL/code. It is completely bioperl dependent at
> the moment. Our discussion about wider ranging infrastructure is
> definitely worth keeping alive but this project is so dependent on bioperl
> there's not much point in pretending otherwise]
> 
> 
> The aim is a pretty vanilla set of SQL tables, quite normalised, nothing
> fancy. The only sticking point are the dreaded feature locations, which,
> if we go the full fuzzy modelling (aaaaarh not the fuzzies again) I
> will need help (jason - can you face the fuzzies again?). 
> 
> At the moment I am going to have a cheeky "unparsed_location" string table
> for the fuzzies.
> 
> 
> To bind to the SQL tables I will have a series of pretty vanilla
> "adaptors" talking Ensembl or FlyBase, equivalent I believe to Java Bean
> singleton objects talking java (? java experts to correct me) which
> mediate persistence of Bio::Seq objects.
> 
> The only wrinkle here is how to deal/detect nicely one-instance style
> objects, such as Species (homo sapiens). I will I hope glean some wisdom
> from Arne Stabenau on this tomorrow but if anyone has some helpful ideas,
> just put them down here.
> 
> 
> For output, it will definitely support appropiate Bio::DB:: *I interfaces
> and probably extend it for simple field orientated queries that can be
> easily mapped to SQL (nothing fancy)
> 
> 
> For input it will have a loader script that can load a SeqIO stream into
> the database.
> 
> 
> It will be able to support mutliple logical "databases" (eg, swissprot and
> genbank) in the same db instance and handle multiple versions of
> sequences. It will not currently handle true entry-granualarity
> mutability, but if anyone has any must-do-now aspects please shout.
> 
> 
> I want to put code in the Bio::DBSQL:: namespace. Is this ok?
> 
> 
> Code will go into the bioperl-db cvs module
> 
> 
> I have a tight-ish deadline on this, so please shout if you feel you want
> to add anything.
> 
> 
> 
> 
> 
> ewan
> 
> 
> 
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>. 
> -----------------------------------------------------------------
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

-- 
David Block
dblock@gene.pbi.nrc.ca
http://bioinfo.pbi.nrc.ca/dblock/wiki
Plant Biotechnology Institute
National Research Council of Canada
Saskatoon, Saskatchewan