byterock

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 Accessor.pm.

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 [

        qw(da_compose_only

           da_no_effect

           da_warning

          )

      ] => (

        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();

   $user->create($utils->connect(),$container); 


   if($user->results()->is_error()){

     #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.