Difference between revisions of "Design Specs: Database Connectivity"

From WormBaseWiki
Jump to navigationJump to search
Line 4: Line 4:
 
databases (multiple instances of the same database in some cases).
 
databases (multiple instances of the same database in some cases).
 
Should be fault tolerant if a server or database crashes.
 
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.
 +
 +
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!!

Revision as of 11:49, 4 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.

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!!