Baby Moose Enviornment

Well is environment day here in the Moose-pen

Today I was going to take on that big test fail mess from yesterday's post but before I go too far along I was troubled by this code change;

my $user = Test::DB::User->new();
--my $result = $user->create($utils->connect(),$container);
++my $result = $user->create($utils->connect(),$container,{raw_query=>1});

Getting warning or debugging to fire off like the above may cause a good dela of trouble to some future programmer. Even in the best case scenario they still have to have edit the code and re-run it to see that SQL, not a good situation. As I see it I will have to make a few changes yet again to

The first change is to nail down the return value from all the CRUD functions, so far I have not defined exactly what that may be. I did check the earlier incarnations of the Data::Accessor code and I found that any result of a CRUD function was placed in a 'results' array_ref attribute. Unfortunately what was placed in it varied with each CRUD function a simple scalar count of records effected for the Update and Delete methods an ID number on Create and an array-ref result sets on a Retrieve.

Well that worked fine for one DB and SQL but I will need something a little more generic for Database::Accessor. To solve this I am going to do is create a new 'results' class and then pass it down for the DAD to fill in pass back to the sub , I will then set a local attribute to that class and return only 1 'success' or 0 an 'error' from the CRUD method.

The good thing about this I can add in all the extra info into this class, success or error, raw_query, underlying db, rows effected etc and use that for testing etc. I will also have to tell the DAD writers that they will have to capture all errors and return just that Database::Accessor::Results class in an error state.

The next little problem is how to turn on some sort of debugging without having to recode. Taking a lesson from DBI I will an 'environment' variable for this as well I will keep them as option params as well. Now the question is do I keep these as just flags or threat them as attributes.

Given that this is Moose I am going to go with the lovely MooseX::Attribute::ENV to help me out and I can quickly get these with code as simple as;

has [
] => (
is => 'rw',
isa => 'Bool',
default => 0,
traits => ['ENV'],

So far I have come up with a few, one that will only compose the query and not execute it, one to stop the underlying db from committing in the case of an SQL db and one to set a warning level for debugging.

So now my call end user code would look something more like this

my $user = Test::DB::User->new();

#handle error here

or if you like

my $user = Test::DB::User->new();
if ($user->create($utils->connect(),$container)){
my $results = $user->results();
else {
#handle error

a little better me thinks. Now to try and code this all up and write out some new tests cases.


Leave a comment

About byterock

user-pic Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations