Its think of something, look it up and skip it day here in the Moost-pen.

Yesterday I added in the first option for Accessor.pm 'only_elements' and that got me thinking, never good ever comes out of that, I should enforce the rule that 'only_element' option has to be a hash-ref.

So I quickly looked-up a MooseX that I know will let me do that 'MooseX::Params::Validate' and reading a little from Dave's POD I should skip this module …

Its wrap up a test day here in the Moose-pen;

I am going to finish off '15_alias.t' today by adding in a few more test looking at the field 'alias' and here are the tests;

$in_hash->{elements}->[0]->{alias} = 'last';

$in_hash->{elements}->[1]->{alias} = 'first';

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

$da->create( $utils->connect(),$container);

ok($da->result()->query() eq "INSERT INTO people sys_users ( sys_users.first_name ) VALUES( ? )","create SQL correct");

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

ok($da…

It is still alias day here in the Moose-pen

So it is day two of looking at aliases and SQL and as part of this I had some time last night to have a peek about the SQL standard. So far I am doing things correctly, for table and field. Though in my first incarnation of table alias I used the 'AS' keyword in there, if you look at some of the check-in history you will see it. This 'AS' will work in a few SQL engines but not all so I was correct in dropping it out.

From my tests of yesterday’s post…

Its get more done day here in the Moose-pen.

Today I was working on new test, '15_alias.t' which I will use to test the various alias attributes found on 'tables' and 'fields' in SQL queries. To start I just have the very simple has with the 'update_requires_condition' and 'delete_requires_condition' flags set to 0 so I can work without a 'where/conditions' clause.

my $in_hash = {

    da_compose_only=>1,

    update_requires_conditio…

Well just another post-ette day here in the Moose-pen

Just another quick post-ette today as I want to quickly add in a feature to the results class that will help end uses with de-bugging.

Presently the results class look like thin when it is dumped

$VAR1 = bless( {

                 'is_error' => 0,

                 'DAD' => 'Database::Accessor::Driver::DBI',

                 'query' => 'UPDATE people SET people.first_name = ?, people.last_name = ? WHERE ( people.first_name = ? AND people.last_name = ? )',

 …

Well test expand posette day here in the Moose-pen.

Not that have the first test in 20_where_basic.t working I figured I might as well expand on that tests and ensure the other SQL clauses are coming out in the format I like. So I added the following in;

my $container =  {first_name=>'Bill',

                  last_name =>'Bloggings'};

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

ok($da->create( $utils->connect(),$container),"created something");

ok($da->result()->query() eq "INSERT INTO people ( people.first_name,…

Still in re-factor mode here at the Moose-pen.

Yesterday I had quite the success in taking a little more of the logic out of the DAD side side of things now the DAD writes not longer have to check to see if a predicate in a condition or filter has miss-matched parentheses or is missing at least the the default 'and' condition.

Before I move on I want to squish this little warning

Use of uninitialized value in join or string at...

ts re-factor day again here at the Moose-pen

With all my test passing since yesterday's post I think it is time I spend a little time re factoring before I move onto other things. Now as I said many times before I would like to have whatever is going to the DAD, Driver::DBI in this case, to be as free of logic errors as possible.

In this vain I noticed that when dealing with a where clause and predicates in general there are a two rules that should be enforced before any conditions …

Well is bug squish day here in the Moost-Pen

Yesterday I manged to get my test to fail properly I guess today I better start looking at fixing the code that is breaking starting with my update;

I left print warn on and in my output I am getting this

DBD::DBM::db prepare failed: Couldn't parse at C:/Dwimperl/perl/site/lib/DBI/DBD/SqlEngine.pm line 340

 [for Statement "UPDATE user SET address = ?"] at 

It is getting all my Baby Moose in a row day here in the Moose-Pen

So after yesterday's major TARFU with five tests failing and worse three tests reporting false positives I think a good review is needed.

The first thing I am going to clean up is the false positive test like this one;

eval{

   $user->update($utils->connect(),

                 $container);

};

if ($@) {

    fail("Update function error=$@");

}
/users/byterock/2018/05/index.html

Its find a flaw here in the Moose-Pen

Well today did start out well and I began work on expanding Driver::DBI a little when I just wanted to check to see if that DBD::DBM driver of mine could do a little more that what I played with in '10_crud_basic.t' and I go it to take this SQL;

SELECT username as name,address, addresses.street FROM users join addresses on users.address = addresses.id

Its Moose day here in the Moose-Pen today.

Still playing about with re-factoring things before I move along too far and what I wan to fix today is this block of code;

package Test::DB::User;

use Moose;

use parent qw(Database::Accessor);

  around BUILDARGS => sub {

      my $orig = shift;

      my $class = shift;

      my $ops   = shift(@_);       

return $class->$orig({

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

             elements=>[{view=>'user',

                         name=>'use…

It a little re-factor days here in the Moose-Pen

So just a quick re-factoring post-ette now that I have the basic CRUD working.

This line of code

my $field = $self->get_element_by_name(sub {$_->name eq $key}); 

This …

It if put the 'D' in CRUD day here at the Moose-pen.

So yeaterday I fininsed off Retreive/Select after I pulled a few hairs out trying to debug and issues that was not there I thouhg today I wiyld finish of my CRUD subs by doing the _delete sub today.

At least this is the most simple of all four functions as there is not need to iterate over fields or contrainers so the code is just;

sub _delete {

    my $self             = shift;

    my …

Well if carry on as if you are normal day here in the Moose-pen

In yesterday's post I manged to get the update sub working with a real DB and today I am going to try the 'retrieve' sub which is a little more tricky.

The basic concept is much the same as for the other two and it really did not take me long to get it up and working, the only real gaff was this one

Subroutine _select redefined at 

Its get more done day here in the Moose-Pen

Now that I have got 'create/insert' to work in yesterday's post I think I will move on down the line and get the next one easy one to work 'update'.

This first thing though is to get rig of this waring;

Commit ineffective while AutoCommit is on-1 at D:\GitHub\database-accessor-driver-dbi\lib/Database/Accessor/Driver/DBI.pm line 64

ok 1 - Create function

Its actually do something day here in the Moose-Pen

So yesterday I left off with my Driver::DBI generating this SQL code;

INSERT INTO user (address,username) VALUES(?,?) 

    my $sth;

    eval {

        $sth = $dbh->prepare($sql);

    };

    if ($@) {

    …

Finanlly a DBI codeing day here in the Moose-Pen

So after yesterday's little review I finally got to do some coding on Driver::DBI and the first thing I got working was my '00_load.t' test case. All I needed to do with the present sate of the code is add in;

my $in_hash = { 

++                           da_compose_only=>1,

                view => { name  => 'name' }};

 

Just another quire review here at the Moose-Pen

Yesterday I summed up what I was up to over the past month or so since I left the Dist-Pen, So tadoy as I am rather sort on time I will just do a quick post-ette on the state of Database::Accessor::Driver::DBI.

Well just for kicks before I revisited any of the Driver::DBI code I re-ran the the very limited test suite of two test case and got a full fail, so I guess every thing is broken.

Looking at the code the first think I noticed was that I have this sub

sub _warn {
my $self = shift;
…

It is cheap clip show day here in the Moose-Pen

Now that I am finally finished with Database::Accessor for the moment as since my last post all my tests are passing, I think it is time for a quick recap of what when on since this post when I left the Dist-Pen and started up the Moose-Pen.

The first few post I set out on writing my first Driver::DAD, I worked out some name-space issues and finally came up with Database::Accessor::Driver::DBI rather than SQL as most DBI drivers run on SQL is just seemed locgial.

The second set of posts I started to write up my Driver::DB…

Just cleaning up the Moose-Pen today.

I left off from yesterdays post with few more tests to clean up and a new one or two to write up. Might as well get the low hanging fruit first and that is this error;

Can't locate object method "dynamic_conditions" via package "Database::Accessor::Driver::Test" at 43_dynamic_conditions.t line 54.

     

/users/byterock/2018/05/index.html

Still stuck in the Accessor.pm in the Moose-pen today.

Since I decided in yesterday's post to make one more round of changes I am a little closeer to getting back to Driver::DBI but not much.

For today's changes I decided to go full out and re-factor a good chunk of the common code between Accessor.pm and any DAD that I might write. Not to bore you with reamls of code pasting you will never read I will give you the over-view.

First action was to strip out the attributes from D…

Test case clean up day today in the Moose-Pen

All those changes I introduced in my last post did quite a job in mucking up my test suite as the latest run results show;

Files=27, Tests=328, 39 wallclock secs ( 0.24 usr  0.06 sys + 36.90 cusr  1.92 csys = 39.12 CPU)

Result: FAIL

Failed 9/27 test programs. 37/328 subtests failed.

="pre…

It is keeping promises day here in the Moose-pen

Keeping in step with yesterday's post I am continuing with my code-review of Accessor.pm. It was suggested that I explain a little more on my reasons for doing most of the validation on the Accessor.pm side rater than the DAD side so here we go.

As today’s title suggests I want to make a promise to the DAD from the Accessor.pm that all the attributes that I have passed down to it are ready to go into a the requested CRUD query, so only a m…

Well no progress day here in the Moose-Pen

After yesterday's post where I decided to much more validation on the Accessor side of things I had a chance to takke a deep and close look at Accessor.pm.

A code review is always a good thing and I found a few problems right from the start, in mose of my CRUD functions I was still doing this

return $container; 

/users/byterock/2018/05/index.html

Well its Accessor.pm post-ette day today here in the Moose-Pen

Yesterday's post I managed to make a very small start on my Driver::DBI before I figured it would be a good idea to do more of the param validation on the Accessor side rather than the driver side. That way I know I will not run into the situation where one Accessor/Driver combination works differently than another.

The validation rule for today is on the $container param for both the Create and Update and is as follows;

'…

Almost some code day here in the Moose-Pen.

Not much code today unlike yesterday's post where I changed eighteen files and checked in one new one.. Today I had a look at how I am going to proceed with Driver::DBI, With all the changes I made to Accessor.pm I have some rethinking to do with Driver::DBI

I will now have to

1. work with a results class
2. capture any errors into the appropriate attribute of that class
3. set the appropriate class attributes on success…

Code clean-up day here in the Moose-pen.

After adding in a few ENV flags in yesterday's post I better get back on track and fix the 16 test cases I broke in this post.

The thing I had to do was modify the 'Database::Accessor::Driver::Test', (remember this one? my DAD for testing), so it returned a 'Database::Accessor::Result' class and the was easy enough and in now looks like

="prett…

Well is environment day here in the Moose-pen

Today I was going to take on that big test fail mess from yesterday's post but before I go too far along I was troubled by this code change;

my $user   = Test::DB::User->new();

--my $result = $user->create($utils->connect(),$container); 

++my $result = $user->create($utils->connect(),$container,{raw_query=>1});

Still Accessor.pm day here in the Moose::Pen.

In yesterday's post I was playing about with the 'raw_query' sub in Driver::DBI and that lead me back into Accessor.pm to make a few changes there. You might remember I had this as a final result in Accessor.pm

="prettypr…

Well some Driver::DBI code today in the Moose-Pen.

Carrying on from my last Post where I had created the new sub 'raw_query' and had it testing nicely I started on my merry way to program the Driver::DBI module. Well I did not get very far along.

I started out with creating a get_sql sub that the 'raw_query' would call, but then quickly realized that that would be a little redundant as any time I needed just the SQL I could just call the 'raw_query' and save a sub. So I came up with this.
/users/byterock/2018/05/index.html