BioPerl-DB
view release on metacpan or search on metacpan
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.
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 )