Its Just a quick post-ette day here in the Moose-Pen

When we last met our hero she had gotten though most of the perils of the ever-changing API and the ever-increasing code base but found one other problem when working on the test in test case '10_crud_basic.t'

$da = $person->da();

$da->add_condition({

                left => {

                    name => 'user_id',

                },

                right     => { value => $new_person->{user_id }},

                operator  => '=',

            })…

Get back on track day here in the Moose-Pen

Well after mulling things over last night I think I will just have to make a note in my API that the 'view' fix will only work for the first layer of 'Link' and I will give a few examples of bets to use this feature and how to avoid problems.

Today I started on practical testing again with the plan being add in a new person/address record and then see if I get the correct values out.

Now to start I created two new Xtest::DA classes 'Address' and 'PeopleAddress' to work with and I instantiate all of these classes using th…

Back to the API day again here in the Moose-pen

To be extra diligent I decided to play about with some of the tests in '40_joins.t' to see if my API was working as I expected. Namly I took this link;

 {

                type       => 'LEFT',

                to         => { name => 'address' },

                conditions => [

                    { operator=>"!=",

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

                        right =>  {

                              function => 'left',
/users/byterock/2018/09/index.html

Its deal with change day here in the Moose-Pen

Today the first thing I am going to fix is this little line of code in Database::Accessor;

foreach my $link ((@{ $self->links },@{ $self->dynamic_links })){

            my $view = $link->to;

            my $alias = !$view->alias ? $view->name : $view->alias;

            $self->_check_element($link->conditions,0,$alias);

           push(@items,$link->conditions);

Its go back and rethink day here in the Moose-Pen

You might remember form yesterday I really did not like this bit of code

               next

                   if ((($field->view) 

                    and ($field->view ne $self->view()->name()) 

                         or ($self->view()->alias() and ($field->view ne $self->view()->alias()))));

A quick postette day may-by here in the Moose-Pen

Well I though I would have a very quick post here today, which is nice as I am still not 100%. I was going to re-run my test-suite end to end and you would think with only '

 2 files changed, 37 insertions(+), 9 deletions(-)

in Database::Accessor there is not much that could go wrong.

First I had these annoying warings again;

 Use of uninitialized value in string ne at /home/scolesj/databaselib/Database/Acc…

ts fix the other bug day here in the Moose-Pen.

The second of the bugs that I am after squishing today was in Driver::DBI and in test case '15_alias.t'
It was dropping the elements/fields from the update command like this

Expected->UPDATE people SET first_name = ?

Generated -> UPDATE people SET 

    my…

It fix a test postette day here at the Moose-Pen

Felling a little better today as the mind is a little less foggy, that might change back on October 17th though?
Today I am going to fix the first of the bugs I ran into yesterday;

Not a HASH reference at ,,,\t\lib/Database/Accessor/Driver/Test.pm line 13

# Looks like your test exited with 2…

Moose-Pen is Back

Sorry I missed a few days it seem that when you have walking pneumonia it can turn into creeping pneumonia very easily. Who knew? I will have to start my year of daily posts again I guess I should be satisfied with 297 consecutive days.

Just a postette for for today and as usual it is just a quick all-up test post. For Database::Accessor it has been a while since I did a full pull on the repo and I got

 6 files changed, 160 insertions(+), 39 deletions(-)

Back to piratical Moose;

You may remember a post a few days ago where I was starting the first of my practical Database::Driver::DBI tests against an Oracle DB I happen to have handy. I ran into problems right away as I was getting this generated SQL;

NSERT INTO people ( city, country_id, first_name, 

                    last_name, postal_code, street, user_id )

      VALUES( ?, ?, ?, ?, ?, ?, ? )

Its piddle with old code day here in the Moose-Pen

Yesterday I managed to clean up the '$container' param and now it only sends down to the DAD only items that match with the present view. After cleaning up all the related tests and adding a few more test in other test cases I have a little time last night to try some piratical use of Database::Accessor.

The first thing I discovered was it is very frustrating to the end user to send a '$container' down to a DAD have something unexpected happen and not know why or at least be able to see what was acted on.

Therefor…

Its take one step forward day here in the Moose Pen

today I am going to try and fix that stoppage I had yesterday. To recap I have a rule in my API that states that I can only 'update' or 'create' on elements that have the same view as the DA. So given this DA hash

{ view     => { name => 'people' },

  elements => [

        { name => 'first_name',},

        { name => 'last_name',},

        { name => 'id', },

 …

Its practical test day here in the Moose-pen

Yesterday I set up a new class that would generate a nice little set of DB table for me on what ever DB the end user may have by using a plug-in to supply the generation SQL. Today I greatly expanded that class but there is no real reason for me to dump it here as it is just more of the same from yesterdays post.

I did create a new class to test complete with a Data::Accesosr definition which is below;

sub _b…

Still extending my Moose tests here in the Moose pen today.

For my next extended tests I will need to have some tables on the target tests database. This of course poses some problems as the DDL (Data Definition Language) of each SQL db is slightly different;

Take dropping a table. You very basic SQL works fine

DROP TABLE people;

DROP TABLE IF EXISTS;

Its extended test Day here in the Moose-Pen

Now that I have what I think is 99.95% of my API set and both Database::Accessor and Driver::DBI are code-complete and passing all test cases, I think is is time to do some practical tests on my system.

By piratical I mead testing on a 'real' SQL db. So far I have been testing with the very limited 'dbi:ExampleP' DBD, and little less limited 'dbi:DBM' and only in two test cases. All the other thests cases I really just check the generated SQL so I have know idea, but a good assumption, that the code will work on a real SQL DB.

Why break a habit day here in the Moose-Pen

Time for another bottom up test run and for Database::Accessor I had

 8 files changed, 317 insertions(+), 237 deletions(-)

Driver::DBI was changed about the same with

 7 files changed, 1056 insertions(+), 835 deletions(-)

Use of uninitialized value …

A little more identity clean-up here in the Moose-Pen today.

As a final clean up I would like this exception test to pass

 {

        caption  => 'on an identity element blocked',

        type     => 'exception',

        key      => 'elements',

        elements => [

            { name => 'id',

              identity =>{'DBI::db'=>{'ORACLE'  => {

                            name => 'NEXTVAL',

                            view => 'products_seq'}

                }} 

            },

…

Its identity round-up day here in the Moose-Pen

I decided to add in another test;

{        caption  => 'have identity option but do not use',

        key      => 'elements',

        elements => [

            { name => 'id',

              identity =>{'DBI::db'=>{'ORACLE'  => {

                            name => 'NEXTVAL',

                            view => 'products_seq'}

                }} 

            },

            { name => 'first_name', },

            { name => 'last_name', },…

Its re-think things day here in the Moose-Pen

Well I eally do not like this part;

 container => [

              {first_name=>'Bill',id=>"",last_name =>'Bloggings'},

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

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

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

              ],

Its still identify day here in the Moose-Pen

Yesterday I made a good start with my 'identity' flag and today I carry on with this using this test;

  {

        caption  => 'use identity option with exe array',

        key      => 'elements',

        elements => [

            { name => 'id',

              identity =>{'DBI::db'=>{DBM  => {

                            name => 'NEXTVAL',

                            view => 'products_seq'}

                }} 

            },

            { …

It running out of things to do day here in the Moose-Pen

So I am getting very close to being code complete on both Database::Accessor and Driver::DBI I thing I only have a few more little things to add. One that I am going to look at today is the problem of 'identity' fields.

97.654321% (a number pulled out of me arse) of SQL DB have some sort of auto-sequence field or a flag on the field to make the primary key auto increment on insert. There is only one main-stream DB that does not have this and that is ORACLE though there are some other out there I might not know about.…

Its rethink my case day here in the Moose-Pen.

Some of my loyal readers (if there are any) my remember when I started playing with the 'Case' statement I had a few iteration with the naming convention for my API. I finally settled on 'whens' that holds all the case conditions and 'statement' for the 'then' part of the case like this;

 whens => [

                    {

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

                        right     => { value => '100' },

                        operator  =…

Test postette day again here in the Moose Pen.

Time to re-run my tests suites again to check the 'Sate of the Onion' before I move on. I expect this will be a very short post.

For Database::Accessor as expected I did not have many changes since last week

 2 files changed, 70 insertions(+), 24 deletions(-)

All tests successful.

Files=29, Tests=490, 81 wallclock secs ( 0.23 usr  0.06 sys + 77.55 cusr  1.71 csys = 79.55 CPU)

Result: …

ts final Case postette day here in the Moose-pen

For the final clean up of Case I am going to add in a few tests in Database::Accessor that should have been there in the first place.

First I will add this;

 whens => [

            {

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

                right     => { value => '10' },

                operator  => '',

                statement => { name  => 'price' }

            },

++          [{

++              left      => { name  => 'Pric…