byterock

Never say never day here in the Moose-pen

Just when I though I had all the bugs out of my Database::Accessor I found a bunch more while finishing off tests case '42_new_validation.t'.

Most of the bugs where with the 'links' attribute. My test for this attribute are a check to make sure a link has a 'to' is present, and it not undef, and the same for type and then at lease on condition is present.

The first bug was

not ok 19 - type is proper link ; links

and the error it was throwing was;

 'links->type' Constraint: The Link 'undef', is not a valid Accessor Link! Try one of 'LEFT', 'OUTER', 'RIGHT'

and the value in the hash we

     'type' => 'bla',

Now I traced this back to a change I did yesterday in the 'Database::Accessor::Types' package to make my subtype fails look a little more user friendly;

subtype 'Link',

  as 'Str',

  where { exists( Database::Accessor::Constants::LINKS->{ uc($_) } ) },

  message {

    "The Link '"

    ._undef_check($_)

    ."', is not a valid Accessor Link!"

    ._try_one_of( Database::Accessor::Constants::LINKS() );

  };

I added in that '_undef_check' and made one little error;

sub _undef_check {

--  my $self = shift;

    my ($in) = shift;

    return $in

      if ($in);

    return 'undef';

}

I have to take out that '$self' there as I am not instated at this point. With that in there I passed that test.
The next was a little harder to pin down;

ok 19 - type is proper link ; links

not ok 20 - conditions is required; links

ok 21 - name required; sorts

At first I thought it was just because I forgot to add the required on that Link attribute;

has conditions => (

        isa     => 'ArrayRefofConditions',

++      required=> 1,

        is      => 'ro',

        traits  => ['Array'],

        handles => { condition_count => 'count', },

        default => sub { [] },

        documentation => "links"

    );

but the error was till there;

You might remember that 'link' has an 'around BUILDARGS' call where I set up the views of the elements in the link. I added in a little debugging and noticed that the in '$ops' came in to that sub as an empty array ref;

'to' => {

            'name' => 'country',

            'alias' => 'a_country'

          },

  'conditions' => []

  'conditionsx' => [

…

So I took out that 'default=> sub {[]}' but the error still hung about. Then it hit on me. I had this

    foreach my $condition ( @{ $ops->{conditions} } ) { 

in that sub and that was setting that key on $ops to empty and thus passing that along. To fix that I wraped that call in a if statement;

        if (exists( $ops->{conditions} )){

            foreach my $condition ( @{ $ops->{conditions} } ) {

               $class->_check_elements( $condition->{left},  $view_name );

               $class->_check_elements( $condition->{right}, $view_name);

            }

        }

and then I got

ok 18 - type is required; links

ok 19 - type is proper link ; links

ok 20 - conditions is required; links

not ok 21 - conditions cannot be empty; links

...

...

so that passed but I still can have empty in there so I had to fix that as well and to do that I had to go back to “” and add this in;

--subtype 'ArrayRefofConditions' => as 'ArrayRef[Condition]'';

++subtype 'ArrayRefofConditions' => as 'ArrayRef[Condition]',

++   where { scalar(@{$_})<=0 ? 0 : 1; },

++  message {

++    "ArrayRefofConditions can not be an empty array ref";

++  };

and now I get;

...

ok 20 - conditions is required; links

ok 21 - conditions cannot be empty; links

ok 22 - name required; sorts

Finally done for this one at least. Onto something else tomorrow I thing I am due a check-in and full tests review.