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.
Leave a comment