byterock

Its big change check-in day here in the Moose-pen

I think there will be very little new code today but I did incorporate a large volume of changes. First I dropped 'Database::Accessor::Roles::AllErrors' as I no longer see any DAD writer ever having any user for it not that it does not throw an error;

The code from that I added into the 'Database::Accessor::Types' and I did not even have to make a single change to the code. I also took out all the commenting out junk code and waring from that class for good measure.

I then went into Accessor.pm and made the following change;

– sub _loadDADClassesFromDir {


++ private_method _loadDADClassesFromDir => sub {

I change any sub that has the '_' over to a private_method. I also changed any attribute with the same '_' to Private as in this example;

 has _ldad => (

        isa => 'HashRef',

        is  => 'rw',

++      traits      => ['Private']

    );

This may not sound like much but the checking tells a different story;

 5 files changed, 736 insertions(+), 340 deletions(-)

Ok here goes a full test suite the first time in a little while;

#     Error:  Can't locate Taint/Util.pm in @INC (you may need to install the Taint::Util module) 

Opps there is the first one must of left that in there someplace;

Once I fixed that I did get this

t/31_elements.t ............. 1/47 Can't locate object method "errors" via package "Moose::Exception::SingleParamsToNewMustBeHashRef" at /home/scolesj/database-accessor/lib/Database/Accessor/Types.pm line 149.

# Looks like your test exited with 255 just after 16.

a few time so I must have jut one bug in there most likely when when I am passing in some sort of param;

This one proved a little tricky and it came about when I was having a $in_hash like this;

{

  'elements' => [

                  bless( {

                           '_lookup_name' => 'Peoplefirst_name',

                           'view' => 'People',

                           'name' => 'first_name',

                           'no_retrieve' => 1,

                           'only_retrieve' => 1

                         }, 'Database::Accessor::Element' ),

                  bless( {

                           'name' => 'last_name',

                           'no_create' => 1,

                           'view' => 'People',

                           '_lookup_name' => 'Peoplelast_name',

                           'alias' => 'user'

                         }, 'Database::Accessor::Element' ),

….

I have blessed objects coming in. This is an anomaly of my test system, I convert that $in_hash into classes, but it is also perfectly valid to enter such a hash so thank you tests for finding yet another bug after all those changes. My test is fine then and the root cause of the error is that I am trying to recreate an object that already exists. The fix is simple enough

sub _create_instance {

    my ( $class, $ops, $caller, $raw ) = @_;

    my $object;

++  return $ops

++    if (ref($ops) eq $class );

and now I have only one error which was a problem with the test itself seems I was a little stale and I had the both the no_retrieve and only_retrieve on at the same time for one 'element' so I just had to flip that;

$in_hash->{elements}->[0]->{only_retrieve} = 1;

++$in_hash->{elements}->[0]->{no_retrieve} = 0;

and now that test case fully passes.

Now another full run;

t/35_links.t ................ Can't locate object method "missing" via package "Can't use string ("to") as a HASH ref while "strict refs" I

well close;

The fix for this one was simple enough;

sub _create_instance {

     my ( $class, $ops, $caller, $raw ) = @_;

     my $object;

    return $ops

      if (ref($ops) eq $class );


     if ($NEW) {

-        $object = $class->new( %{$ops} );

+        $object = $class->new( $ops );

     }

 

Just swap out the older '%{$ops}' as I will never get an 'Class' here and I am always calling this directly from another sub now so no longer need to force that $ops into a hash.

The full run now gives me just this one

t/58_parenthes.t ............ 44/49 Database::Accessor retrieve Effor: Unbalanced parentheses in your dynamic attributes. Please check them! at /home/scolesj/database-accessor/lib/Database/Accessor.pm line 905

That one had nothing to do with the Unbalanced parentheses this line of the test;

$da->reset_gather();

was failing and I had to do this in Accessor.pm to fix it;

     sub reset_gather {

       my $self = shift;

-      $self->dynamic_gather();

+      $self->dynamic_gather(undef);


     }

and now I get

All tests successful.

Files=30, Tests=583, 37 wallclock secs ( 0.16 usr  0.03 sys + 36.58 cusr  0.92 csys = 37.69 CPU)

Result: PASS

so good night;