byterock

It is start something new day here in the Moose-Pen

Today I wanted to start writing up my first Database::Accessor::Driver, so I quickly came up with this

package Database::Accessor::Driver::SQL;

BEGIN {

    $Database::Accessor::Driver::SQL::VERSION = "0.01";

}

use Moose;

with(qw( Database::Accessor::Roles::Driver));

sub execute {

    my $self = shift;

    my ( $type, $conn, $container, $opt ) = @_;

    $container->{dad}  = $self;

    $container->{type} = $type;

}

sub DB_Class {

    my $self = shift;

    return 'dbi';

}

1;

Ok easy enough and I also added one quick test like this;

#!perl
use Test::More tests => 1;
use Test::Fatal;
use lib ('t/lib');

use Database::Accessor;

my $da     = Database::Accessor->new($in_hash);

my $return = {};

$da->retrieve( Data::Test->new(), $return );

Well I quickly noticed that I have to solve two things before I even able to get the first test to run

1. Rename the 'DAD' name-space in Database::Accessor
2. Figure out how to get a valid DBD handle into my test when I may not know which DBD the end client may have handy.

So the first problem did not take long to work out. One good thing is that I embedded the original DAD role in the Accessor.pm file I did not have to rename a directory. In the end the first check-in to git-hub was about seven file changes. Now after that the first 'dzil test t' run I get

 Looks like you planned 44 tests but ran 45.
# Looks like you failed 1 test of 45 run.

So looking very sweet with that change. The fail was in the case t/20_dad_load.t and the exact faile was

...
ok 6 - Role DAD attribute: gathers is Read Only
not ok 7 - Role DAD can available_drivers
#   Failed test 'Role DAD can available_drivers'
#   at t/20_dad_load.t line 46.
ok 8 - Role DAD can sorts
...

After a few mins of poking about I found this;

    has available_drivers =>(
        isa => 'ArrayRef',
        is  => 'rw',
        documentation=>"Returns an ArrayRef of HasRefs the DADs that are installed. The keys in the HashRef are 'DAD=>DAD name,class=>the DB class,ver=>the DAD Version'"
    );

in Accessor.pm. Seems I forgot to add in a little more to this new attribute. Like some other attributes I need to tell my test that is is not in the DAD and one quick change;

    has available_drivers =>(
        isa => 'ArrayRef',
        is  => 'rw',
++   traits  => ['MooseX::MetaDescription::Meta::Trait'],
++   description =>{ not_in_DAD=>1 },
        documentation=>"Returns an ArrayRef of HasRefs the DADs that are installed. The keys in the HashRef are 'DAD=>DAD name,class=>the DB class,ver=>the DAD Version'"
    );
 

and I do not need to adjust the test count on t/20_dad_load.t as I am going to skip that test so a on my next 'zil test t' I get

All tests successful.
Files=26, Tests=317, 32 wallclock secs ( 0.21 usr  0.05 sys + 29.63 cusr  1.74 csys = 31.63 CPU)
Result: PASS

so one cannot be more pleased that that.

Now the second question and I think I have my topic for tomorrow as I may have to chance the name of the whole projects as I name naming it Driver::SQL what if I am not using DBI?? so maybe Driver::DBI?? and what if the DBD of the handle in question does not use SQL?

Oh well at least I proved test based development is good. I did that name-space change in only a few mins.