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
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" …
I was getting the error because all of the attributes in elements of the test $…
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…
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;
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
so some major changes. On my first rung to the test cases I got fairly poor results with 14 test cases failing. The majority of fails were tests I invalidated by my code changes from the past few days;
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.html
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…
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 => '…
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…
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.
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;
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'
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 =>…
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 …
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.
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…
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 =>…
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()){
where it checks to ensure the class is present but I think in the way I am designing the API I should die well before this as I do in a number of other similar si…
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
opps; Better install that and try again.
After that was installed I got somewhat better results;
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( $…
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…
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…
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 …