byterock

My little API exercise in my last post I noticed that I may be missing an important part of the puzzle and that is some sort of generic connector function.

The present perl code DA.pm does have this:

 
sub _connect {
   my $self = shift;
   return $self->_dbh()
      if ($self->_dbh());
   my $dbh;
   if ($self->cache_connection()){
      $dbh = DBI->connect_cached($self->data_source,$self->username,$self->password,$self->connect_attr);
   }
   else {
      $dbh = DBI->connect($self->data_source,$self->username,$self->password,$self->connect_attr);
   }
   $self->_dbh($dbh);
   return $dbh;
}

Obviously it assumes that you would be using a DBI and returning a database handle. Not much use if you want to use Mongo as the data source. So putting my abstraction cap on I came up with this simple three param call

 

  $DA->connect({artibute1=>x,...},$user_name, $password) ;

Now what am I going to do with that connection? Am I going to store that connection someplace locally for reuse, cache it someplace else or I am going to return a new connection and replace the old one?

At first look addeing support for handling connections in my API seems to be what I should do but I see this as being problematic.

Connecting tends to be a very resource intensive activity, in RDBMs anyway, so one wants to keep that connection about, so one usually caches it. Just look up Connection or Cache on the Map of Cpan you will will come up with a cornucopia of differing connectors, connection caches etc, and that is excluding the build in ones like DBI's connect_cached or others buried under a name-space such Apache::DBI::Cache. There also is the other concept of a connection Pool there are a number of those out there as well.

The simple fact is connecting and connection caching is a problem that has been around for a long time and there are many tools out there to 'Fix' it. I know myself I have used differing tools depending on what I am doing. On multi-threaded Plak app I used DBIx::Connector the next day on a stand alone cron job I just used the DBI's connect_cached, thinking about how Ihave used Data Accessor in the past, I can't seem to recall a time when I use the built in connection sub.

So I am asking myself do I want my Data Accessor to take on that responsibility? I would never be able to cover every use case and what ever I come up with will either be too much or too little for a large chunk of the user base out there.

I could just pass this along to the coder who has to write the Data Accesor Driver but that will just annoy that person and more than likely they will not get it right either or not even not bother to write one.

So I think I am going to take a different tack on things and drop connecting and connection caching out of my spec entirely and place responsibility of getting a proper connection in the hands of the coders who are going to use be using an instance of my Data Accessor.

The same thing can be said for data retrieved by the Data Accessor why should I cache it. I could easily do it but I would never do it right for every use case and I could see it causing all sorts of problems. So why not drop that as well

So here is the new spec for my CRUD orations, I will just do Retrieve to save some space,

 
   $da->retrieve ($connection,$container,$options);

where

• $connection is a valid contention for the Data Source Driver
• $container is a ref to a hash, array or an object to load the data into
• $options just a place where a hash ref or alike can be passed to the Driver

Now I wonder if this is going to work out or have I done this to myself again?