Its another quick test postette today in the Moose-Pne

So things are moving along now I just just going to finish off '57_dad_elements.t so it will be a short one today. Nothing much to Add I just have to add in dynamic link, gather, and sort.

Well sort should by the most easy one so I will do that one first; All I did was copy out the last (5th) item in the main hash and added it in like this;

$da->add_sort({

            expression => '+',

            left       => { name => 'salary', },

            right      =…

Its back to view day here in the Moose-Pen

Today I am going to carry on with getting full coverage for test case '57_dad_elements.t' and fixing the bug I found in yesterays post.

First the bug. I am missing the view in the last left of this nested element;

...

    bless( {

                 'predicates' => bless( {

                                          'operator' => '=',

                                          'left' => bless( {

                                                       'left' => bless…

It the great test round up here in the Moose-Pen today

Since I have done at least two major changes in the design of Database::Accessor over the past few post I figure I better give the whole test suite the once over to see what breaks. Here are the results of the first run;

Test Summary Report

-------------------

t/11_link.t               (Wstat: 65280 Tests: 4 Failed: 1)

  Failed test:  4

  Non-zero exit status: 255

  Parse errors: Bad plan.  You planned 8 tests but ran 4.

t/18_condition.t          (Wstat: 65280 Tests…

Its condiment day here in the Moose-Pen

Now it is time to play catch-up with my Database::Accessor and make the same changes for 'links' that I did for 'conditions'.

First off I could create a new Role as both share the same basic attribute again but I think I will not do that and instead do this;

        package 

           Database::Accessor::Link;

        use Moose;

        extends 'Database::Accessor::Base';

++ has predicates => (
++ is => 'rw',
++ isa =>…

Its test round up day here in the Moose-Pen

Now that my baby Moose is almost all grown up it is time to go back and look at some of the missing bits in my test suits. In my last post I fixed up the default 'view' for all the 'element' attributes that my be present on a Database::Accessor.

I have checked my test suite and I at least test the elements attribute to a few levels of recursion in '31_elements.t'. Looking at that test suit I think I will pull the eight 'view' tests out of there and and create a new test case '="https://github.com/byterock/database-accessor…

Its nip a bug day here in the Moose-Pen.

Over the past few days I have been slowly cleaning up my tests and now I am going to fix one more little problem I was having with Database::Accessor; Setting the 'view/table' of an element/field that is being passed down into a DAD.

I do have this working for most of the parts that I am sending down to the DAD but I am still missing this functionality on the 'sort/order by' so lets look at that test as a start;

my $tests = [{

    key  =>'sorts',

    sorts => [

            …

Another test postette today here in the Moose-Pen;

Carrying on from yesterday I took the time today to first add in this to my new test call

...

    $da->retrieve($self->connect());

--    my $ok =   ok(

++    my $ok =   ok(

        $da->result()->query() eq $test->{sql},

        $test->{caption} . " SQL correct"

    );

++    unless($ok){

++      diag("Expected SQL--> ".$test->{sql}."\nGenerated Out-> ".$da->result()->query()); 

++    }

…

It quick postette day again here in the Moose-Pen

Just a quick one off re-factor for today. In the past few days I have been using a code snipitte like this;

my $tests = [{

    key  =>'sorts',

    sorts => [

             {name => 'last_name',

              view => 'people'

            },

            {

              name => 'first_name',

              view => 'people'

            },

            ],

    caption => "Order by ",

    sql     => "SELECT people.first_name, peop…

Its sort day here in the Moose-Pen.

Well I have been on a role since I started on 'Group By' so I figure I might as well get the last of the base SQL code snippets in place. The last one is 'sort' or in SQL 'ORDER BY' and why change something that isn't broke here is a new test case '60_order_by.t' and here it the hash I am going to start with;

my $tests = [{

    key  =>'sorts',

    sorts => [

             {name => 'last_na…

It another gather day here in the Moose-Pen.

Now that I did the re-factoring for gather it is time to move on the Driver::DBI and do to code to generate the SQL. Of course I always start with a test case and this time it is a new one 50_having.t. It is much the same as the other test cases so no need to repeat that here, the only important bit is this hash;

my $tests = [{

    index=>0,

    key  =>'gather',

    gather =>{

…

Its gather in the dream day here in the Moose-pen

Well going to skip a post on creating a gaggle of new tests today and instead do some core coding in Driver::DBI and Database::Accessor. Now believe it or not I had a dream last night that something was wrong in the way I set the architecture of Grathers and Filters, GROUP BY and , HAVING in SQL, in Database::Accessor. Boy this does sound corny!. So today I started to look at that part of my code.

In the original Data::Accessor a 'GROUP BY' and 'HAVING' looked like this

  {   …

Its link day here in the Moose-Pen

Well seeing as my elements/fields and conditions/Where are working quite well I think it is time to move on to the next attribute in Accessor.pm Links.

In SQL joins are the same as Database::Accessor Links so given this SQL;

SELECT people.first_name, people.last_name, people.id, address.street FROM people LEFT JOIN address ON people.id = address.user_id WHERE people.first_name = ?

LEFT JOIN address ON people.id = address.…

Its where day in the Moos-Pen

Today I am going to expand on the '20_where_basic.t' test case going from a simple one level Element to Param 'where clause' such as

SELECT people.first_name, people.last_name, people.user_id FROM people WHERE ( people.first_name = ? AND people.last_name = ?

First I decided to re-factor my tests from the start and using the 'element_sql_ok' sub from this post I re-fact…

Just another quick test postette day here in the Moose Pen.

As we seen in this post I found a bug where I was not coercing correctly on deeply nested Element Attributes. So that means back into the test suite of Database::Accessor I go to cover that bug and the new recusion functionality I have added recently.

Checking the current state of the test suite I see that I never did go deeper than one level of elements, though I do check to ensure that the View on elements are correct and the correct …

Its re-factor test postette day in the Moose-Pen

Over the past few days I have made up quite a few tests and they where all the same pattern

• Base hash
• add function/expression element
• create DA
• run select/retrieve
• check SQL
• check parms

The re-factoring was quite simple, I took my test;

/users/byterock/2018/06/index.html

Its get fancy day here in the Moose-Pen

Now that I have 'Functions' nicely working I am going to move on to the next logical field and that is an 'Expression'. In SQL (and 99.9% of other languages) an expression is just a predicate that can be evaluated. So an SQL like this

SELECT user.username, user.salary + 10 FROM users WHERE username='BOB'

="pre…

It carry on with recursion day here in the Moose-Pen

Carrying on from where I left off in yesterday's post I was about to add in this new test;

$in_hash->{elements}->[0] = { function => 'substr',

                                 left  => { name => 'username' },

                                 right => [{ param =>3},{ param =>5}] };

my $da = Database::Accessor->new($in_hash);

$da->retrieve( $utils->connect() );

ok(

    $da…

Its get back into Driver::DBI day today here in the Moose-Pen

I decided to get a little more ambitious and see it I can get Driver::DBI to handle a function call in an SQL select, like this;

SELECT user.username, 

             left(user.username,11), 

             user.address 

FROM user 

WHERE user.username = 'Bill'

It is test catch up day here in the Moose-pen.

I figured it is a good thing to review the state of the test suites for both Database::Accessor and Driver::DBI and starting with Accessor.pm I get this;

t/20_dad_load.t           (Wstat: 1024 Tests: 53 Failed: 7)

  Failed tests:  6, 12, 18, 24, 51-53

  Parse errors: Bad plan.  You planned 50 tests but ran 53.

t/30_view.t               (Wstat: 256 Tests: 9 Failed: 1)

  Failed test:  5

  Parse errors: Bad plan.  You planned 10 tests but ran 9.

t/31_elements.t  …

Back to the Field day here in the Moose-Pen

Today I am going to give params and containers a miss and move back into the '30_fields.t' test that I left alone so long ago. One of the planned concepts in Database::Accessor it the ability to have static data as part of the elements array. This is accomplished by using the 'Param' class in place of the “Element' class so you could do an SQL like this

SELECT 'User Name:', username, 'Address:', address FROM user

Quick postette day here in the Moose-Pen.

So yesterday I had left over SQL error that I wanted to have a look at. The error was

FROM locations WHERE *>.city =

$new_da->add_condition({left  =>{ name  => 'city',

                               },

                      right =>{ value => $other_user}

                    });

Just prove it worked day here in the Moose-pen

So yesterday I left off with my SQL looking correct but my query failing on the DBD::DBM so to-day I though I better just do a quick postette just to prove to my many readers that my code actually works.

So I all did was write up this quick little script

#!perl

use DBI;

use Data::Dumper;

use Database::Accessor;

my $dbh = DBI->connect("DBI:Oracle:",

        "a user id" ,

        "a password");

my $new_da = Database::Accessor->new({view=>{name=>…

Its get very ambitious day here in the Moose-pen.

As things went just a little to smoothly over the past few post I though it would be a good day to try something that I know is going to cause me grief. In the vain I added this test;

use Database::Accessor;

my $is_bill = Database::Accessor->new({view=>{name=>'user'},

                                          elements=>[{name=>'username'}],

                                          conditions=>{left  =>{ name  => 'username',

                                view  => 'us…

Its still param day here in the Moose-Pen

Carrying on from yesterday's post I, today I added in one more test;

ok($user->update( $utils->connect(),$container),"update with present container");

$user->reset_conditions();

$container = [{address =>'MNO'},

              {address =>'PQR'},

              {address =>'STU'},

              ];

$user->add_condition({left  =>{ name  => 'username',

                                vie…

It playing with update and container day here in the Moose-pen.

Now that I have the 'create' function working so well with execute_array I figured the next logical step would be to do 'update' function but I have one small problem. When I attempt to do this;

$container = [Test::User->new({username=>'Bill',address =>'ABC'}),

              {username=>'Jane',address =>'DEF'},

              Test::User->new({username=>'John',address =>'HIJ'}),

              {username=>'Joe',address =>'KLM'},

              ];

$user-…

Well is still container day here in the Moose-pen.

So now that I have the 'execute_array' all fixed up and working I think I will carry on the same past and get the container to work with an array of 'classes'. In that end I created this little class;

package Test::User;

use Moose;

has username => ( is  => 'rw',

               isa => 'Str',);

has address => ( is  => 'rw',

               isa => 'Str',);

1;

Well it is look at another module day here in the Moose-Pen.

So yesterday I ran into this problem;

DBD::DBM::st execute_array failed: 4 bind values supplied but 2 expected [for Statement "INSERT INTO user ( user.address, user.username ) VALUES( ?, ? )"] at …

$dbh->{RaiseError} =…

Well it get lucky postette day here in the Moose-Pen.

Well I left off yesterday a little worried that I was only testing half of the execute_array as I never actually got down into the DBI code of things. So I decided lets give it a try on that pre-installed 'DBD::DBM' that I used in my '10_crud_basic.t' test case as according to the DBI docs there shold be a defult implimentsion of 'execute_array''

Well I opened that sucker up and added this in

…

Its a little harder day here in the Moose-Pen.

Carrying on with adding to the '32_params.t' case I though today I would tackle one of the harder parts of prams and that is passing an array of params or in my case containers into a query statement.

So in my test I could have this;

$container = [{first_name=>'Bill',last_name =>'Bloggings'},

              {first_name=>'Jane',last_name =>'Doe'},

              {first_name=>'John',last_name =>'Doe'},

              {first_name=>'Joe',last_name =>'Blow'},

       …

Its fix typo and a little programming day here in the Moose-Pen.

Before I get back on track and start working on test case '32_params.t' but before that I had to clean-up in my code. Seems I had 'parenthes' all over the place when it should really be 'parentheses' so the last thin I did last night was clean all those up. Thank goodness for Padre and it search and replace functions.

Anyway on to '32_params.t' and the fist thing I did was cut out some tests from other places and put them in there as it made a little more logical sense. From 20_where_basic.t I striped out al…