Never Ending API Moose

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.

untitled-4-p1-e1511116407137.jpg

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