Its start the long releases cycle here at the Moose-Pen

Today I am going to examine some of the results I got from my 'Devel::Cover' run.

ffile                     stmt bran cond sub  pod time total

lib/Database/Accessor.pm 94.4 80.0 88.8 93.7 0.0 23.5 91.7

The next col branch has 80% and following that link I get

/users/byterock/2018/11/index.html

Another test day here in the Moose-Pen

Today I am going to go though all the tests in my Driver::DBI and see what explodes

Not really expecting a good run I was plesenlty surprised when I got;

\t\20_fields.t         (Wstat: 512 Tests: 88 Failed: 2)

  Failed tests:  86, 88

  Non-zero exit status: 2

\t\90_extened.t        (Wstat: 65280 Tests: 0 Failed: 0)

  Non-zero exit status: 255

  Parse errors: Bad plan.  You planned 11 tests but ran 0.

The first on…

Its big change check-in day here in the Moose-pen

I think there will be very little new code today but I did incorporate a large volume of changes. First I dropped 'Database::Accessor::Roles::AllErrors' as I no longer see any DAD writer ever having any user for it not that it does not throw an error;

The code from that I added into the 'Database::Accessor::Types' and I did not even have to make a single change to the code. I also took out all the commenting out junk code and waring from that class for good measure.

I then went into Accessor.pm and made the followin…

Another sad day in the Moose-Pen

Not a good way to start another year of blogging as I was reviewing my tests and when I got into '47_dynamic_gathers.t' I was getting a duplication on the number of conditions on a gather which is not a good thing.

Somewhere in the last few days I really buggered something up.

Well after much hair pulling and debugging I finally stumbled into it. It seems I have added so many warns and comment out code over the past few days I was playing with subs that look like this;

sub _predicate_array…

Final final final clean up day here in the Moose-Pen

Just a quick postette today cleaning up the last of my messages on my error retruns. Starting with this one;

 'Database::Accessor Database::Accessor::add_condition Error:

 The following Attribute is required: (conditions->left)

 With constructor hash:

 {

   'predicates' => {

                     'operator' => undef,

Its get back on track day here Moose pen.

I left off with the add_sort and did some refracting that when a little awry but I did get back on track. As it stands I have this original

 sub _element_coerce {

    my ($hash) = @_;

    my $object;

    if ( exists( $hash->{expression} ) ) {

        $hash->{expression} = uc( $hash->{expression} );

        $object = Database::Accessor::Expression->new( %{$hash} );

    }

    elsif ( exists( $hash->{function} ) ) {

        $hash->{function} = uc( $hash->{…

Is may be the end of the errors Day here in the Moose-Pen.

I spen quite a bit of time mulling over the various options and possible solutions to the rater large mess I made yesterday with my recursive call to a eval.

I did manage to do a very long coded version where de-factored my code back to what it was when I starter earlier this week. A block of code for each 'undef' sistuation.

I wasn’t really satisfied with that as it was ugly, unmaintainable and I think very fragile once I got into more that two levels of recursion on my evals.

What to do?

Still stuck in error land in the Moose-Pen.

As I finally got the 'add_condition' to work I still needed to add in a few more tests for the other three 'dynamic' attributes, gather, link and sort.

Well I started with the easiest first 'sort' and on the 'undef' I am getting the now very familiar;

Attribute (name) is required at D:\GitHub\database-accessor\lib/Database/Accessor/Types.pm line 348

As thi…

It is another shame day here in the Moose-pen

I never like taking out code but that is the first thing I had to do today. So all the code changes from yesterday have been rolled back and I still have the same problem;

Attribute (predicates) does not pass the type constraint because: Validation failed for 'Predicate' with value undef (not isa Database::Accessor::Predicate) at D:\GitHub\database-accessor\lib/Database/Accessor/Types.pm line 349# 

="pretty…

Still cleaning in here in the Moose-Pen

Well was all ready to move onto the final documentation and distzila stage of Database::Accessor and then I ran into a few little tings when I reran the full test suite.

First there was this annoying warning;

Use of uninitialized value $error_package in string eq at \GitHub\database-accessor\lib/Database/Accessor/Roles/AllErrors.pm line 59.

        my $on ="";

--      if ($error_package eq…

Still in mop up mode here in the Moose-Pen

I finally found a way (well not a good one) to generate an even better error message to my end users. You are of course quite familiar with this type of message;

Database::Accessor add_condition Error:

The following Attribute is required: (Element->name)

Its never stop improving day here in the Moose-Pen

As I was cleaning things up today I found yet another little improvement I can do to my error messages. Right now when I have deeply buried bad item such as the 'names' in this $in_hash

$in_hash = {

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

    elements => [ { name => 'first_name', }, { name => 'last_name', }, ],

    gather    => {

                elements => [

                    {

                        name => 'first_name',

                        view…

Final final clean up day in the Moose-Pen

Just a few quick things here in the Moose-Pen today. I want to make sure that my '_one_error' sub will return the same style of results no matter from where it is called and I want to make sure the 'DA_ALL_ERRORS' $ENV var is respected.

I did the $ENV first at that was a little tickly; I made this change in Accessor.pm

        if ($@) {            

--        if (exists($ENV{'DA_ALL_ERRORS'}) and $ENV{'DA_ALL_ERRORS'} ){

--              die $@;

--          }

--       …

Its hold your head in shame smarty pants day here in the Moose pen.

So here I am with a little 'mea culpa' for yesterday post. I had what you would call a real newbie flaw to to that I should of caught right away.

Now it was not in the re-factoring or the implantation of the re-factoring that was all ok my problem was assuming that the coercion of my objects was not happening on a new. Of course it was so when I hit the test where I had an coercion error on new on a coerced object I was getting a double fail that would wash out my original fail.

The real problem i…

Its another re-factor day here in the Moose-Pen

I left off yesterday with a little re factoring to do. I had essentially the same code for handling construction errors in Accessor.pm and in Types.pm. In any other object orientated language I ever worked with this would be rather a pain to fix. Even in plain perl one would have a few problems getting things just right.

Fortunately I am using Moose.

The great thing about Moose a Role can consume another Role. So all I needed to do was suck out all the code I need from the 'around BUILDARGS' call in Accessor.pm and…

Its discovery day here in the Moose-Pen

I was all ready to wrap up my 'new' constructor errors when I figured I better see what I get when I do something like this;

$da->reset_conditions();

$da->add_condition( {

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

            operator          => '=',

        },);

Attribute (left) is required at D:\GitHub\database-acces…

Well its fix one break everything day here in the Moose-Pen

I thouhg it was just going to be one of those quick look how well things pass postette days today but I was dead wrong;

I did a check in a a quick push and then ran the full test suite and got

t/20_dad_load.t ............. Attribute (conditions) does not pass the type constraint because: ArrayRefofConditions can not be an empty array ref at /usr/local/lib/perl/5.18.2/Moose/Object.pm line 24

        Moose::Object::new('Database::Accessor', 'HASH(0x2eeb320)') called at t…

Never say never day here in the Moose-pen

Just when I though I had all the bugs out of my Database::Accessor I found a bunch more while finishing off tests case '42_new_validation.t'.

Most of the bugs where with the 'links' attribute. My test for this attribute are a check to make sure a link has a 'to' is present, and it not undef, and the same for type and then at lease on condition is present.

The first bug was

not ok 19 - type is proper link ; links

Its make and mend day here in the Moose-Pen

Now that I have my constructor single error working the way I like I figure I better go back and clean up my test cases and create a new test case just to check the error on 'new' construction.

I am going to start with '30_view.t' as that is the one I have been mucking with most over the past little while.

The first thing I did was strip out the new 'validation' tests and suck them in a new tests case '42_new_validation.t' and after a few adjustments it presently looks like this;

m…

Another postette day here in the Moose-Pen

I had only one little goal today and that is come up with a really nice single construction error message. After a good hour or so of mucking about I finally came up with;

The following Attribute is required: (view->name)

The following Attribute did  not pass validation: 

'view->alias' Constraint: Validation failed for 'Str' with value [  ]

With constructor hash:

{

  'elements' => [{ name => 'first_name', }, { name => 'last_name', }],

  'view' => {

        …

Its quick add in day here in the Moose-Pen

Today I am going to add in another attribute called 'all_errors' a simple Boolean flag so my end user can either get a single error message of all the errors found or the 'MooseX::Constructor::AllErrors' object with all the errors when using the 'new'. Simple enough I can just add it here

 has [

        qw(all_elements_present

++         all_errors

          )

      ] => (

        is          => 'rw',

        isa         => 'Bool',

        default     => 0,…

Its very bad form day here in the Moose-pen

Today I wanted to clean up one thing on construction error handling namely getting the correct number of errors back on my 'AllErrors' object.

First a little house cleaning. The first thing I did today was create a new sub called '_new_misc_error'

 sub _new_misc_error {

        my $self = shift;

        my ($error,$line,$filename) = @_;

    

        my $misc = MooseX::Constructor::AllErrors::Error::Misc->new({message =>"Database::Accessor New Error: "

        …

Its dig deep an play day here in the Moose-Pen

I my last post I figured out how to set up Database:Accessor to get the 'MooseX::Constructor::AllErrors' object in the 'around BUILDARGS' and then play with it, without breaking my existing code.

Today I want to see if I can change my error messages. I started by poking about in guts of ' MooseX::Constructor::AllErrors' and I discovered the the error messages are rather had coded;

sub message {

…

Still make errors pretty day here in the Moose-Pen.

$in_hash = {

    view => {

        name  => undef,

        alias => undef

    }

};

eval { 

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

    };

ok( $@->has_errors(),          "Error on New" );

ok( scalar( $@->errors ) == 2, "Two errors on new" );

...

Still error day here in the Moose-Pen

One thing I wanted to try and do was have a little more meaning in my error-messages much like I did yesterday when my error message put out something like this

Database::Accessor create( $db 'Class', $container 'Hash-Ref||Class||Array-Ref of [Hash-ref||Class]', $options 'Hash-Ref'); Error: Incorrect Usage:  The $container 'Array-Ref' must contain only Hash-refs or Classes. $container=$VAR1 = [

          1,

          {

            'last_name' => 1

          },

          ble…

Its pull hair day here in the Moose-Pen

Yesterday I merrily finished off all the changes where I swapped out die for confess and the changes where I updated the error messages to the same standard. I then happily check in Accessor.pm and was looking forward to a quick testing post for today. happily finished and checked the lot in. Then tried to run my test suite an got;

t/00_load.t ................. 1/1

#   Failed test 'use Database::Accessor;'

#   at t/00_load.t line 7.

#     Tried to use 'Database::Accessor'.
…

Still error day here in the Moose Pen.

As I am a little lazy today and I didn't have time to work on this project last night, there was a Godzilla film festival on last night, it just a quick postette today.

I went though all the Database::Accessor code today and cleaned up at least the format of my die calls.

Looking about at a number of other applications I figure I might as well go with the semi-standard CME or 'Class', 'Method', 'Error' style.

Lets take this first example the Die that one could run into and that is found in the BUILD sub of Database::Acc…

Its error day here in the Moose Pen

Well not really error day more like lets have a look at the errors I spit out and attempt to standardize them, but that is too long for a catch title.

First thing to do was have a look at how my Accessor.pm and from a review I see that I only use 'die'. I found it in about 22 spots in the code. The good thing is I don;t have a mixture of croak, die and croak
carp and confess. The bad thing is I wad never very consistent with my die messages;

Most are just simple strings such as

A…

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

It seems I am getting close to finishing off Database::Accessor and Driver::DBI. I have a very complete test suite for both and an extensive practical test suite for Driver::DBI and all three are running at 100% pass. I should be happy.

Well I am not. The practical testing did show me one major API change that I should make.

If one of the main advantages of Database::Accessor is that it can protect the data in your DB from injection attacks and from backdoor queries that can find things out about your Data or even chan…

Its Big Boss day here in the Moose-Pen

I was thinking of continuing on with the gum-shoe motif in my post but once it funny twice is dull and three times is just annoying so I will just dive into the real work for today. Looking at the test suite of Driver::DBI and fixing what has broke since I changes up the API all these many days ago.

I ran the full suite and the only one that failed was 't/40_joins.t' and it dies with about 300 lines of of waring and fails. Fortuntely 90% of them where;

Use of uninitialized value in hash elemen…