BioPerl-DB

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

refactored and architected from scratch since the previous branch
bioperl-release-1-1-0. Meanwhile almost everything works. The
following things are unsupported or do not work yet:

     - sub-seqfeatures
     - round-tripping fuzzy locations (they will be stored according
	  to their Bio::Location::CoordinatePolicyI interpretation)
     - Bio::Annotation::DBLink::optional_id

To understand the layout of the API and how you can interact with the
adaptors to formulate your own queries, here is what you should know
and read (i.e., read the PODs of all interfaces and modules named
below).

1) Bio::DB::BioDB acts as a factory of database adaptors, where a
database adaptor encapsulates an entire database, not a specific
object-relational mapping or table. It is similar Bio::SeqIO in
bioperl, where you specify a format and get back a parser for that 
format. Here you specify the database and get back a persistence 
factory for that database. Note that the only database really 
supported right now in this framework is BioSQL.

README  view on Meta::CPAN

created or found in the database. A persistent object will still
implement all interfaces and all methods that the non-persistent base
object implements. E.g., a persistent sequence object will implement
Bio::DB::PersistentObjectI and Bio::PrimarySeqI (or Bio::SeqI).

4) A persistence adaptor will implement Bio::DB::PersistenceAdaptorI. 
Apart from actually implementing all the persistence methods for 
persistent objects, a persistence adaptor allows you to locate 
objects in the database by key and by query. You can
find_by_primary_key(), find_by_unique_key(), find_by_association(), 
and find_by_query(). The latter allows you to formulate object queries 
as Bio::DB::Query::BioQuery objects and retrieve the matching objects.

5) The guiding principle for the redesign of the adaptors was to
separate business logic from schema logic. While business logic is
largely driven by the object model (hence, by the bioperl object
model) and therefore is mostly independent from the schema, but
specific to the object model, the schema logic is driven by and
specific to the relational model. The schema logic will therefore need
to differ from one schema to another and even from one schema flavor
to another for very similar relational models, whereas the business



( run in 0.261 second using v1.01-cache-2.11-cpan-3cd7ad12f66 )