byterock

Still in API land here in the Moose-Pen

Yesterday I left off with a working API change that stopped users from entering a 'view_elements' on a dynamic 'gather/order by' that was not in the 'elements' array of the Database::Accessor instance. Now that is nice but it also got me thinking what about on some of the other 'dynamic' add, so I added this;

$da->reset_conditions();

$da->add_condition( 

{               condition => 'AND',

                left   => { name => 'salary' },

                right  => { value => '5' },

                operator  => '>',

            }

);

$da->retrieve($dbh);

ok( scalar($da->result()->set()) == 0,"No records returned");

test to the '30_where_basic.t' test case and when I ran it I got results

not ok 5 - No records returned

and when I peeked into the set I did see I returned all the records that had a 'salary' over 5. So there is another back door here. Now I can't find out what the sarary is as I can't add to the 'elements' array but I could figure out who at 'ACME Inc' makes more money than me.

Ok back to the API drawing board.

I will have to first have a test and I think it might be best to add all of these dynamic add 'element' not in 'elements' test in the same test case so I am going to create a new one called '40_dynamic_not_present.t'. I will take the test from '47_dynamic_gathers.t' and start with this modification.

my $in_hash = {

    view => { name => 'People' },

    elements => [ { name => 'first_name', }, { name => 'last_name', }, ]

};


my $params = {

    gather => {

        exception =>

"in not in the elements array! Only elements from that array can be added",

        query => {

            elements => [

                {

                    name => 'first_name',

                    view => 'People'

                },

                {

                    name => 'salary',

                    view => 'People'

                }

            ],

            view_elements => [

                {

                    name => 'first_name',

                    view => 'People'

                },

                {

                    name => 'salary',

                    view => 'People'

                }

            ],

        }

    }

};

foreach my $action (qw[gather]) {

    my $da        = Database::Accessor->new($in_hash);

    my $command   = "add_" . $action;

    my $exception = $params->{$action}->{exception};

    like(

        exception { $da->$command( $params->{$action}->{query} ) },

        $exception,

"$action Not allowed to add elements that are not in the elements attribute"

    );

}

and give it a run and it should pass;

ok 1 - gather Not allowed to add elements that are not in the elements attribute

which it does. Now all I need to do is add in the other 'dynamic' adds I want to test.

I did do another piratical test to see if I need to do this on a sort and I found you can with this code;

$da->reset_sorts();

$da->add_sort({name=>'salary',

               view=>'people',

                descending => 1});


$da->retrieve($dbh);

while not giving me the 'salary' I know who has the higest.

So that only leaves link/join and I could see where one could easily do this with this 'link/join';

            links => {

                type       => 'right',

                to         => { name => 'people',

                                    alias   => 'p2' },

                conditions => [

                    {

                        left  => { name => 'id',

                                   view => 'p2' },

                        right => {

                            name => 'id',

                            view => 'people'

                        }

                    },

                   {

                        left  => { name => 'salary',

                                        view =>'p2' },

                        right => {

                            value => '6',

                        },

                       operator=>">"

                        condition=>'AND'

                    }

                ]

            },

which did give me a large record set but I can still find out who has a salary of over '6' by simply ignoring the records with null which are the ones that do not match the j'oin/gather'.

Therefor all four have to be tested and I will have to spend some time just thinking about this one as I can see that I might be able to do some re-factoring that will save me problems in other areas.

I think that is it for today as I really have to sit down and work this all out.