June 2018 Archives

A Mature Mosoe

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;

expression => '+',
left => { name => 'salary', },
right =…

Big Moose Almost Ready

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…

Big Moose All in a Row

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…

Big Moosse Catches up

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;

use Moose;
extends 'Database::Accessor::Base';

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

Moose Growing Pains

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…

Big Strong Moose

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 => [

No Longer a Baby Moose

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

-- 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());
++ }

What the above do…

Just a Baby Moose

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…

Sorting Out Baby Moose

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…

Gather Up Even More Moose

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 = [{
key =>'gather',
gather =>{

Gather Up Baby Moose

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

{ …

Baby Moose Link

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.…

Baby Moose Where?

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 = ?

to the much more complex Function, Expression, nested and mixed clauses that I was using in the last few posts.

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

Back to Momma Moose

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 …

Matureing Baby Moose

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
so a little re-factoring is in order me thinks., Though there is a school of thought that it is a waste of resources to re-factor working test. Fortunately I do not ascribe to that thought so here we go.

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


Baby Fancy Moose

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'

In Database::Accessor I have an Expression class for this and it works 90% the same as the Function class I just finished. Thus this expression;

Baby Moose Recursion Dance

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() );

Ambitious Baby Moose

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,
FROM user
WHERE user.username = 'Bill'

The way I have planned to do this is Database::Accessor with the 'Function' class, which has a simple string attribute for the function name and it is used with 'Comparator' role…

Baby Moose Clean Up

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 …

Baby Moose in the Field

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

Why one wold want to do that I am not 100% sure on thou…

Happy Sunny Moose Day

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 =

so I had no view in the where predicate;

$new_da->add_condition({left =>{ name => 'city',
right =>{ value => $other_user}

Baby Moose Proof

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

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=>…

Baby Moose Takes Charge

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'},
conditions=>{left =>{ name => 'username',
view => 'us…

Another Baby Moose Break

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");
$container = [{address =>'MNO'},
{address =>'PQR'},
{address =>'STU'},
$user->add_condition({left =>{ name => 'username',

Baby Moose Break

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'},

Baby Moose struts his stuff

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',);

Now the next thing I needed to do was make a test out of what I fixed yest…

Yes Baby Moose had a Bug.

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 …

Which rather peeved me as I tried the same code on two other DBs and the both ran. So it it just me? I took a look at example in the DBI POD;

$dbh->{RaiseError} =…

Baby Moose Has a Bug?

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

An Array of Baby Moose

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'},

Baby Moose Makes a Stand

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…

About byterock

user-pic Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations