Less Moose more Elk

Well back to clean up mode in the old Moose-pen today as I have completed my first round of changes to my Database::Accessor embedded classes. Just taking a quick peed at what might attributes might be missing from my I see that my Predicate is missing something important at least to any logical predicate. That is the ability to add parentheses to a predicate.

Well the way I see it I can just make this a Boolean flag attributes such as 'parentheses' but that takes a good deal of flexibility from the system. So what I am going to go for is two flags one for open and one from close, like this


has open_parentheses => (
is => 'rw',
isa => 'Bool',
default => 0,
alias => [qw(open open_paren)]
);

has close_ parentheses => (
is => 'rw',
isa => 'Bool',
default => 0,
alias => [qw(close close_paren)]
);


So simple enough I simply supply a way for the user to turn off and on parentheses as they require them for their data models. I am not 100% happy with this as a user could do mistakes like this one

condition => [
{
open_paren => 1,
from => { name => 'email' },
to => {
name => 'id',
view => 'invited_by'
}
},
]

where they open a parentheses never closed it. At the Accessor level there is no hope of me tying to stop this sort of mistake I will have to leave it up to the DAD writer to catch mistakes like this as I am sure the end DB will.

So now onto a little integration of all those Classes into the Attributes of my Accessor. First I have noticed that I yet to spend any time looking at what the correct types and coercion for Accessor attributes, other that view and elements, so lets look at 'conditions' first


has conditions => (
is => 'ro',
isa => 'ArrayRefofPredicates',
coerce => 1,
default => sub { [] },
);

I see that I have it as an ' ArrayRefofPredicates' however that is not what I want this to be. It should be an Array Ref of Condtion classes so inorder to make that change I need a new subtype 'ArrayRefofConditions'. Like the other subtypes I follow this pattern in my Types Role

  • use the new class

  • add in the type for the class

  • add in the collection subtype

  • and a coerce for that subtype


Nothing we haven't see before.

Now how to test?

I do have my 'Database::Accessor::DAD::Test' hanging about so it is about time that I use it. Now In any test situation it is always good to know what the result of your tests it. To simplify my test I will make my Test DAD only return a simple sting that I can compare to the expected results

So in my first test case I want to end up with this string

RETRIEVE-->View-->'People'-->Elements-->'People.first_name', 'People.last_name','People.user_id'-->Condtion->People.user_id=test-->AND--> People.first_name=John

in the return buffer on my a 'Retrieve' sub.

Now to do the above I first have to instantiate an Accessor like this


my $user = Database::Accessor->new(
{
view => {name => 'People'},
elements => [{ name => 'first_name',
view=>'People' },
{ name => 'last_name',
view => 'People' },
{ name => 'user_id',
view =>'People' } ],
conditions=>[{ left=>{name=>'user_id',
view=>'People'},
operator=>'=',
right=>{param=>'test'}},
{ condition=>'AND',
left=>{name=>'first_name',
view=>'People'},
operator=>'=',
right=>{param=>'John'}},]
}
);

then do this

my $return_str = undef;
my $dad = Data::Test->new();
$user->Retreive($data,$return_str);

and then check to see if I get the expected results

ok($return_str eq”ETRIEVE-->View-->'People'-->Elements-->'People.first_name',
'People.last_name','People.user_id'-->Condtion->People.user_id=test-->AND-->
People.first_name=John”,'Got the correct result');

Now to get that to work in test case 33_conditions.t,

But that is another post.

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