Obda-/-Biosql

I posted the slides for the Bioperl-db/BioSQL talk I gave at BOSC03.

-hilmar

Hi Everyone,

Apologies for the mass cross-posting but this email is about server and IP changes that will affect all of our projects and servers.

Simply put – Wyeth, the company that provides us with our hosting and wonderful T3 connection to the internet is cutting their internet connection circuits over from one ISP to a different Tier 1 internet backbone.

Do you need to access sequences from multiple places? Would you like to easily retrieve your own local sequences from indexed flat files, all other sequences on species X from department wide raletional database and the rest from global internet servers?

The Open Biological Database Access (OBDA) System was designed so that one could use the same application code to access data from all three of the database types by simply changing a few lines in a “configuration file”. This makes application code more portable and easier to maintain.

Hilmar writes:

I got the Oracle version of the biosql schema fully migrated, at least as far as I can tell from here. I’m going to commit the new version some time today. There will also be a sql*plus migration script from pre-Singapore to the current version that supposedly keeps your data intact (be sure to read the disclaimer though).

This means we’re getting ready to release Biosql 1.0, possibly as early as next week. If anyone sees any problems with the current schema that he/she thinks should be corrected before this release, please speak up now. I guess I should make an effort and generate an updated ERD before release; the dated ones are confusing wrt the current schema. If there is consensus I’ll put out a release candidate early next week.

Hilmar writes:

Here’s the background.

The current code in the bioperl-db adaptors to biosql run the connection with AutoCommit off, which means the client determines the transaction. Load_seqdatabase.pl (the main script for loading databases into biosql) treats one sequence entry as one transaction. If any sql statement required for loading the sequence fails unexpectedly, the whole transaction is rolled back, otherwise it is committed once the entry and all its annotation went in successfully. The emphasis rests on ‘unexpectedly’: INSERTs may fail due to unique key violations, which is caught and triggers a look-up of the affected entry by unique key. E.g. a dbxref may already exist; if so, it needs to be looked up in order to establish the association with the bioentry.