byterock

Well did a little more playing about with my applied roles on my DA.pm and added in a bunch more testing to see if things where working for me.

First I wanted to see if using a role twice caused any ill effects so I added

 

ok(

    $address->retrieve( 'DBH', $result ) eq

      'SELECT  street, city, country FROM person  AS me',

    'SQL correct'

);


ok(

    $address->retrieve('MONGO') eq

      'db.person.find({},{ street: 1, city: 1, country: 1}',

    "Mongo Query correct"

);

ok 9 - SQL correct
ok 10 - Mongo Query correct
ok 11 - SQL correct
ok 12 - Mongo Query correct

which is good I can flip between LSDs without much problem. Then I though that there could be some code bleed between the roles so in DA::LSD::Mongo I commented out the with statement

 

– with qw(DA::Roles::API)


++ #with qw(DA::Roles::API);

So obviously the 'DA::Roles::API' is applied in the first call to 'retrieve' and sticks about.

I wanted to see how bad this bleed-out is so I added a sub ping to SQL and a sub pong to Mongo and added in these tests before the final two

 

eval {

    $address->pong();

    pass("address can pong");

};

if ($@) {

    fail("address cannot do a pong");

}


eval {

    $address->ping();

    pass("address can ping");

};

if ($@) {

    fail("address cannot do a ping");

}

ok 11 - address can pong
ok 12 - address can ping

Ouch! that will cause problems. Using roles like this causes the common subs like '_execute' to be overwritten on the role apply but extra methods, and attributes as well, do like our Aussie cousins say 'Hang around like a fart in a phone booth'.

So this blead of code that will really screw up the consitant API I want to make. Just think of the the mayhem that would result if a sneak an LSD in there wiht out the requited subs, simply by loading one with the correct role first. Mogo calls to DBI and vice versa.

Defintly not the way I want to go.

So it is back to the drawing board.

Anyway here is a picture of some cute kittens to make up for this short post