[Bioperl-l] Re: BioSQL or chado

[Hilmar Lapp]

Hi Nat,

On Wednesday, July 30, 2003, at 05:40  AM, Nathan ((Nat)) Goodman wrote:

> Thanks, everyone, for the helpful comments!
>
> Hilmar wrote:
>> I gave an extensive talk at BOSC03 on biosql and bioperl-db, and I can
>> email you the slides if you are interested.
>
> Yes, the slides would be great!

I'll send them along, and also to everyone else who emailed me to 
request them. Or somebody can refresh my memory on how I put something 
up on the website for download; that'd probably be the easiest.

>   I'm starting to feel my way through the
> code.  I gather that to make class XXX persistent, I create a
> Bio::DB::BioSQL::XXXAdapter class, yes?  Seems simple enough... 
> (famous last
> words :)

Yes, if you're talking about making a class persistent that isn't yet. 
There is an abstract base class Bio::DB::BioSQL::BasePeristenceAdaptor 
that you inherit from and that implements all the mundane stuff. You 
just have to override those methods that the base implementation can't 
figure out for you, like what are the object properties to be 
persisted, what are the objects it depends on in a foreign key sense, 
and how to get and how to set the properties' values.

If you're talking about making an object persistent at runtime 
(provided the class is supported by the adaptors), it's simpler than 
that:

	$db = Bio::DB::BioDB->new(-database => "biosql", /* connection params 
*/);
	$my_persistent_obj = $db->create_persistent($my_obj);
	# then insert
	$my_persistent_obj->create();
	# or manipulate then update
	$my_persistent_obj->store();

	# or find an existing one
	$adp = $db->get_object_adaptor($my_obj);
	$my_persistent_object = $adp->find_by_unique_key($my_obj);
	# either manipulate and update, or e.g. delete
	$my_persistent_object->remove();

>
> I should have made my needs a bit more clear.  I want to use existing
> schemas and adapters for existing BioPerl classes.  I accept the
> responsibility to create schemas and adapters for new BioPerl (or 
> BioPerl
> wannabe) classes I write, and hope that others will do the same for 
> BioPerl
> classes they write.

Bioperl-db doesn't support all bioperl objects yet, only the sequence 
and annotation related ones: sequences, clusters, features, locations, 
all of the annotation bundle, ontologies, species.

One of the things in bioperl-db is now that you have a nice framework 
for setting up your own persistence adaptor, requiring you to only pay 
attention to those things that are special about the class you want to 
persist.

I should probably add a disclaimer that that doesn't mean that 
bioperl-db is simple code that can be easily understood in its 
entirety. It's a relatively generic OR mapper, and learning to 
understand the flow of instruction is maybe a daunting task at times. 
On the other hand, the base implementation provides lots of trace 
output if verbose mode is enabled, so it's usually not hard to get a 
good picture of what's going on if you need to.

>  I expect to access the database through BioPerl only
> (except for occasional admin purposes) which means that the only 
> features
> I'll ever use are ones that are visitble through BioPerl.
>

Then maybe the combination of biosql and bioperl-db is for you.

> I'm trying to hitch my wagon to the schema that has the most mature 
> BioPerl
> binding and that is likely to be most widely adopted by the community 
> of
> BioPerl developers (so that the BioPerl binding will continue to 
> improve).

I'm not sure about the current level of adoption of biosql among 
bioperl developers. It used to be relatively quiet in summer last year, 
which was when I picked it up. Given the list activity more recently, 
it seems to have picked up interest at a number of places. Among people 
closer to the bioperl core, except for myself I know that Elia's group 
has been using it, and Ewan's used it to replace SRS.

Ewan also spent an extensive amount of time at the last hackathon to 
try and document how to set up a working biosql/bioperl-db environment 
from scratch, including installing mysql or Pg (which took most of the 
time I believe) and instantiating the schema.

	-hilmar
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------