Difference between revisions of "Design Specs: Database Connectivity"

From WormBaseWiki
Jump to navigationJump to search
Line 12: Line 12:
  
 
Currently, each database is a "Service".  When the API is instantiated, connections are made to each required service.  Database handles are cached.  When a database handle is needed, the service first checks to see if it is live, if not it refreshes the connection.  This would probably be the ideal location to implement failover -- check the current connection, if dead, try a different database server.
 
Currently, each database is a "Service".  When the API is instantiated, connections are made to each required service.  Database handles are cached.  When a database handle is needed, the service first checks to see if it is live, if not it refreshes the connection.  This would probably be the ideal location to implement failover -- check the current connection, if dead, try a different database server.
 +
 
 +
  Failover can be implemented through Moose method modifier 'around'
 +
around 'dbh' => sub {
 +
    my $orig = shift;
 +
    my $self = shift;
 +
   
 +
    my $species = $self->species;
 +
   
 +
    # Do we already have a dbh? HOW TO TEST THIS WITH HASH REF?
 +
    if ($self->has_dbh) {
 +
$self->log->debug("    gff-dbh for $species exists and is alive!");
 +
return $self->$orig;
 +
    } else {
 +
$self->log->debug("    gff-dbh for $species doesn't exist yet; trying to connect");
 +
my $dbh = $self->connect($species);
 +
    }
 +
};
  
 +
 
 
Note also that these Services use Moose "Roles" to define shared methods and variables like connect().
 
Note also that these Services use Moose "Roles" to define shared methods and variables like connect().
  

Revision as of 16:56, 10 February 2010

Objectives

Part of the WormBase::API. Needs to be able to connect to multiple databases (multiple instances of the same database in some cases). Should be fault tolerant if a server or database crashes.

Resources

The current connectivity code is part of the API. The API, in turn, is inside of the lib directory of the WormBase mercurial repository:

http://bitbucket.org/tharris/wormbase/src/tip/lib/WormBase/API/Service/

Currently, each database is a "Service". When the API is instantiated, connections are made to each required service. Database handles are cached. When a database handle is needed, the service first checks to see if it is live, if not it refreshes the connection. This would probably be the ideal location to implement failover -- check the current connection, if dead, try a different database server.

 Failover can be implemented through Moose method modifier 'around'
around 'dbh' => sub {
   my $orig = shift;
   my $self = shift;
   
   my $species = $self->species;
   
   # Do we already have a dbh? HOW TO TEST THIS WITH HASH REF?
   if ($self->has_dbh) {

$self->log->debug(" gff-dbh for $species exists and is alive!"); return $self->$orig;

   } else {

$self->log->debug(" gff-dbh for $species doesn't exist yet; trying to connect"); my $dbh = $self->connect($species);

   }
};


Note also that these Services use Moose "Roles" to define shared methods and variables like connect().

Here's the acedb service:

http://bitbucket.org/tharris/wormbase/src/tip/lib/WormBase/API/Service/acedb.pm

The acedb service "consumes" the generic Service role:

http://bitbucket.org/tharris/wormbase/src/9009075c4c5a/lib/WormBase/API/Role/Service.pm

This nomenclature and structure is a bit confusing and probably needs to be streamlined/refined!!