Its not the end of a story but the beginning of one here in the Moose-Pen today.
When we last saw our hero he was deep into the lair of the dreaded API change gang, Fending off invalidated tests cases left right and center until there was only one left!!
The much to be feared! Test case 't/58_parenthes.t'.
The first error was;
not ok 11 - OR added to last gather condition predicate
$da = Database::Accessor-…Its test fix up day again in the Moose-pen.
Well this post will look very similar to one I did a few days ago. Fixing tests that where invalidated by extending the API to stop users from entering dynamic attributes with elements that are not in the elements array.
The first nasty one I ran into was on '31_elements.t' where I got this fail;
Can't locate object method "_lookup_name" via package "Database::Accessor::Function" …
Its pick and choose day here in the Moose-Pen
So I have made a decision to drop the new feature of checking dynamic adds as they come in. Fortunately I did this in a branch so all I really have to do is drop that branch from my repo and carry on where I left off.
Now before I do that I did have some good ideas while I was working with this branch which I plan to keep.
The first bit of code I am going to keep is the 'get_element_by_lookup' changes. I found this sub more useful than '_get_element_by_name' as the latter incorporates both the name and the view in the loo…
If back-paddle postette day here in the Moose-Pen
My great re-factoing did not really work as well as expected. I has a suspicion, when I started working on the re-factoring, that I would have trouble with the 'parenthesis' check. I though the problem would crop us when adding two or more conditions on separate 'adds' where I open the parenthesis on the fist on and close it on the last.
Fortunately I had a test case, '43_dynamic_conditions.t ', that tests this situation exactly;
my $in_hash = {
conditions => [
…Its test day again here in the Moose-pen
Today I am working of a separate branch 'trigger_dynamic' as I am trying out a large re-factotring of the code. The switch to the branch and then a pull I have
4 files changed, 341 insertions(+), 67 deletions(-)
1/12 Gather view_el…Still API day here in the Moose-Pen.
The first thing I did today was save all my work to github and create a new branch so I can work on that trigger idea I had yesterday.
This time out no need to write a test first my present test cases should be all that I need so I can dive right into the code today;
The fist code change I made was to comment out all the code that relates to the '' call for dynamic attributes, not need for that here. Next I changed the name of the trigger function;
-- sub _check_elements_present {
/users/byterock/2018/10/index.htmlIts re-factor day here in the Moose-Pen
The first thing I got to today was complete the test case '40_dynamic_not_present.t' for all four dynamic attributes. No need to dump the many lines of very similar hash-refs here but here is the latest results from the case above;
not ok 1 - add_condition attribute->condition only allowed to add elements that are in the
elements attribute
ok 2 - add_gather attribute->view_elements only allowed to add elements that are in the
elements attribute
not ok 3 - add_gather attribut…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 => '…Its even more API Day here in the Moose-Pen
In yesterday's post I found a back door to fields in a DB that are not part of a Database::Accessor instance. I was able with this 'gather/group by'
da->add_gather({elements => [{name => 'user_id',
view => 'people'},
{name => 'salary',
view => 'people'}],
/users/byterock/2018/10/index.htmlIt try it out day here in the Moose-Pen
With that new API in hand lets give a practical test in my 'xt' dir another go. Starting with this test;
my $regions_count = $user_db->regions_count_data();
$da->only_elements();
$da->add_gather({elements => [{name => 'description',
view => 'region'},
{ name => 'user_id',
view => 'people' }],
view_elements=>[{name => 'description',
…Still playing with the API here in the Moos-Pen today.
Now that I have that new API for 'Gather/Group By' I will have to update how Driver::DBI works. Starting with the new test in the 50_group_by.t test case.
{
caption => "group by with 2 elements and 2 view_elements",
key => 'gather',
gather => {
elements => [
{
name => 'first_name',
vie…Back to the API day here in the Moose-Pen
Well I was just going to do a simple test post-ette today but on my first run I ran into this in the '30_view.t' test case for Database::Accessor;
Can't call method "view_count" on an undefined value at D:\GitHub\database-
accessor\lib/Database/Accessor.pm line 762.
# Looks like your test exited with 255 before it could output anything.
Its even more moose day here in the Moose-Pen
For those of you who might have been a little disappointed that there has not been much Moose in my posts of late today you are in for a treat.
Yesterday I had the problem where I may have a nice Database::Accessor all set up that returns all the people in a DB. Good and nice but now I wanted to group them by 'region' which I could do like this;
$address_da->only_elements({region=>1});
$da->add_…Back to basics here in the Moose-Pen
Still expanding my 'xt' tests after yesterday fix. Going to try the “Like” operator to start;
$da->add_condition(
{
left => {
name => 'user_id',
view => 'people'
},
operator => 'Like',
right =>{value=>'atkinst%'}
},
);
Go back again day here in the Moose-Pen
Yesterday I was stymied by not being able to select out just one 'element/field' from a Database::Accessor before I sent it in as part of a condition. I did have something in place an option on my retrieve called 'only_elements'. Time to open up the API once more and make this an attribute that I can set on the Database::Accessor but I do not need to pass down to the DAD as I plan to do the filtering in the same sub 'get_dad_elements'
To start I wi…
Is why tinker with a good thing day here in the Moose-pen
Just carrying on with my extended or as I like to call it my practical test cases. I figure I can skip the rest of the simple where conditions as I have already used most of them in the previous test cases. To start I added a new test case '32_where_operators.t' with this test;
$da->add_condition( {
left => {
name => 'id',
view => 'people'
},
right => [ { value =>…It carry on as if normal day here in the Moose-Pen.
The next little test I want to try out is this one;
$da->reset_conditions();
$da->add_condition(
{
left => {
expression => '*',
left => { name => 'id' },
right => { param => '3' }
},
right => { value => '12' },
operator => '=',
}
);$da->retrieve($dbh);
my $peo…
Its just a extend even more post-ette day here in the Moose Pen
Well going to start on another test case today this time '30_where_basic.t'. Now I do not have to test some of the more basic 'where' conditions as I have already proved that they work from all the other tests cases that use them so what I am going to start out with today is a function as part of a condtion;
First of course is my test;
my $user_db = Xtest::DB::Users->new();
my $dbh = $user_db->connect();
my $people = $user_db->new_person_data;
my $da …It test post-ette day here in the Moose-Pen
Why stop a habit and as usual ona Saturday I am goting to to a quick post on the current state of the test suite for Database::Accessor and Briver::DBI.
Not a lot of changes in Accessor today
3 files changed, 151 insertions(+), 48 deletions(-)
t/11_link.t (Wstat: 65280 Tests: 11 Failed: 3)
Failed tests: 9-11
Non-zero exit status: 255
Parse errors: Bad plan. You planned 8 tests but ran 11.
…
It carry on day here in the Moose-Pen
Today I am just going to carry on with a few 'xt' tests in my '25_exe_array.t' test case. Now I started out wanting to do an update with the execute array so I came up with this test;
$da->reset_conditions();
my $update_people = $people->update_people_data();
my $updated_people = $people->updated_people_data();
ok($da->update($dbh,$update_people),"Update Four New Users ");
ok($da->result()->effected == 4,"Four row effected");
Back into extended test mode here in the Moose-Pen;
Time to get back to some more practical tests as I have been side tracked by a few API issues. Just to re-cap the practical tests are found in the 'xt' dir and I am using them to test Driver::DBI against a real DB. So far this practical testing has sniffed out a whole lot of bugs and I am hoping to sniff out a few more.
Today I am am going to play with the DBIs 'execute array' this should be totally transparent to the end user all I need to do is pass an 'Array-ref' into my $da as the container and DBI::Driver should do th…
Still API clean up day here in the Moose-Pen
It has been a long running battle between myself,m the API and the the 'Link' objects. A number of posts over the past few weeks have been dealing with how to handle the 'view' for the various elements on link.
Today I started down the path of enforcing the API rule that all 'elements' in a link must have a view. So given this link;
links => {
type => 'LEFT',
to => { name => 'address' },
conditions =>…Its clean up day here in the Moose-pen
There are still a few little things to clean up before I move away from record-sets. The first issue I think would be when I have asked for a 'Class' with 'da_result_set' but I have not supplied a 'da_result_class'.
In my Driver::DIB code I did add in this;
if ($self->is_Class() and $self->da_result_class()){
Its the last result_set day here in the Moose-pen.
Going to try and get the final 'da_result_set' 'Class' to work today, and by now it should not take very long.
The first thing I did was update '20_dad_load.t' yet again but this time I will not bother to show the tests as they should be like an old hat by now.
I then added in a new attribute
has da_result_class => (
is => 'rw',
isa => 'Str|Undef',
default => undef,
);
Fix a little bug day here in the Moose-pen
One of the great things of tests based development is you are always finding new bugs as you progress. Yesterday I found yet another;
Given this link/join
links => {
type => 'LEFT',
to => { name => 'address',
alias=> 'test' },
conditions => [
{
…Test postette day here in the Moose-Pen
Been a few days since I did a bottom up test on Database::Accessor and seeing it is a rainy Saturday I figure I could do a quick on.
Starting with Database::Accessor I do not suspect much to go amiss as I only had ' 2 files changed, 41 insertions(+), 6 deletions(-)' but one never knows;
Can't locate MooseX/Enumeration.pm in
After that was installed I got somewhat better results;
All tests successf…Its get back to 'da_result_set' to-day in the Moose-pen.
Getting back on track with 'da_result_set' I still have two JSON which should be quite straightforward and Class which could be problematic, so I am going to JSON first.
I will need a test first of course so the fist thing I will do is add that into '20_result_sets.t'
$da->da_key_case('Lower');
$da->da_result_set('JSON');
ok($da->is_JSON ==1,"return set is a JSON");
cmp_deeply( $…Even more API fun day here in the Moose-Pen
When I left off yesterday I had everything working nicely but I was left with a little problem;
What should I do about the case of hash-keys returned from the DB?
Now in DBI I have three choices
It still fix API day here in the Moose-pen
Yesterday I left off with a new attribute for may Database::Accessor and DAD, 'da_result_set' and I was just going to play with this in my Driver::DBI but before I go and do this I better change one test a little;
first I had this test near the end of my '20_dad_load.t' test case;
...
else {
my $dad = $da_new->result()->error;
ok($dad->is_ArrayRef ==1,"DAD…Its back to the API day here in the Moose-pen
As my practical tests against a real DB are humming along I noticed that I was missing some-thing quick basic on my API namely retrieving more that just a array-ref of data from the DB. Reading some of my earlier posts I did leave this part to latter so I better do it now before I get too close to my first release.
Now in the present Data::Accessor that Database::Accessor is based off of I noticed that I could pass in an optional $container on the 'retrieve' method and depending on the nature or the 'container' it would handle the…
It still expand Test day here in the Moose-Pen.
Carrying on with my extended 'xt' tests or as I like to call them practical test. I wanted to make sure that I can change the conditions on my Database::Accessor and and check that all the DB is correct in the 'person' table.
To accomplish this I added in the following;
$test_data = $user_db->people_data;
$da->reset_conditions();
$da->add_sort({name=>'id'});
$da->retrieve($dbh);
cmp_deeply( $da->result()->set, $test_data,
"All Persons result …
Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations
