Merging bug fix for relying on same order when doing simple hash key iteration.
|Failed to load latest commit information.|
|lib/Bio||_find_by_unique_key - bugfix|
|model||updated to reflect schema changes|
|scripts/biosql||[RT 44466] remove corba-related scripts, now obsolete|
|sql||Unfinished attempt to make this file palatable to the transform_sql.p…|
|t||Fix various Taxonomy values that are tested. Yes, this will break again.|
|.gitignore||ignore conf file|
|Build.PL||Build.PL now checks for DBD drivers and attempts to DTRT|
|Changes||updates since last release|
|LICENSE||added GPL License|
|MANIFEST.SKIP||update skipped files|
|onto-term.patch||Patch file needed for bioperl 1.2.1 in connection with bioperl-db.|
The bioperl-db package contains interfaces and adaptors that work with a BioSQL database and serialize and de-serialize Bioperl objects. =================================================================== Information about BioSQL and bioperl-db =================================================================== This project was started by Ewan Birney with major work by Elia Stupka and continued support by Hilmar Lapp and the Bioperl community. It's purpose is to create a standalone sequence database with little external dependencies and tight integration with Bioperl. Support for more databases and bindings in Java and python by Biojava and Biopython projects is welcomed, and a working prototype was one of the accomplishments of the February 2002 hackathon in South Africa. All questions and comments should be directed to the bioperl list <firstname.lastname@example.org> and more information can be found about the related projects at http://www.bioperl.org and http://www.open-bio.org. I. Scripts located in the scripts/ directory: biosql/load_seqdatabase.pl - a very flexible script to load sequences into a BioSQL database biosql/bioentry2flat.pl - dump sequence data into rich sequence format flatfile from a BioSQL database biosql/load_ontology.pl - load GO or SOFA ontology data into a BioSQL database biosql/merge-unique-ann.pl - script used by load_seqdatabase.pl, it merges features and annotations biosql/update-on-new-date.pl - script used by load_seqdatabase.pl, it will update based on date biosql/update-on-new-version.pl - script used by load_seqdatabase.pl, it will update based on version biosql/cgi-bin/getentry.pl - example CGI script that fetches from a BioSQL database biosql/clean_ontology.pl - "cleans" an ontology in a BioSQL database without foreign keys biosql/del-assocs-sql.pl - script used by load-seqdatabase.pl, removes annotations and features biosql/freshen-annot.pl - script used by load-seqdatabase.pl, removes annotations and features biosql/load_interpro.pl - deprecated biosql/terms/add-term-annot.pl - load ontology terms read from a file biosql/terms/importrelation.pl - load relations between ontology terms and bioentries biosql/terms/interpro2go.pl - load from interpro2go file corba/caching_corba_server.pl - setup a corba sequence caching server corba/test_bioenv.pl - test the bioenv of a running server corba/bioenv_server.pl - setup a CORBA sequence server There is also a script called scripts/load_ncbi_taxonomy.pl in the BioSQL package that loads taxonomic data from NCBI. Most users use this script to load the NCBI taxonomy into their Biosql databases before loading sequences with load_seqdatabase.pl. II. Some background information and how it all works: The adaptor code in Bio::DB and Bio::DB::BioSQL was completely 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. 2) The persistence factory returned by Bio::DB::BioDB->new() will implement Bio::DB::DBAdaptorI. It allows you to obtain a persistence adaptor for an object at hand, and to turn an object into a persistent object. 3) A persistent object will implement Bio::DB::PersistentObjectI. A persistent object can be updated in and removed from the database. It also knows about its primary key in the database once it has been 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 logic is unaffected by this. This had two consequences. First, the user interacts with the adaptors without knowing anything about the specific schema behind it. All interaction takes place in object space. You construct queries by specifying object slots and the values they should have or match. Joins and associations are also specified on the object level (cf. Bio::DB::Query::BioQuery). Internally, the respective drivers for the particular schema translate those queries into schema-specific SQL queries. The second consequence was that every persistence adaptor is divided into two layers, the persistence adaptor itself which does not contain a single SQL phrase or query, and its schema-specific driver which implements those functions which cannot be accomplished without actually doing the concrete object-relational mapping. =================================================================== Information about Bio::DB::Map modules and database interface =================================================================== These modules have been deprecated and are no longer in the distribution.