December 2017 Archives

Off The Moose Track

Well off track again. So I am not going to do my bit on coercion today after all. If anyone out there was actually downloading my code and running my tests you might see this;

Load of Database/Accessor/DAD/ failed:
Error=Can't locate Database/Accessor/DAD/ in @INC (@INC contains: D:\GitHub\DA-blog\lib D:\GitHub\Replay\lib C:/Dwimperl/perl/site/lib C:/Dwimperl/perl/vendor/lib C:/Dwimperl/perl/lib .) at (eval 378) line 2.

Database/Accessor/DAD/Types (Database::Accessor::DAD::Types) may not be an Database Accessor Driver…

Moose in Sheepish Clothing

Now to get back on track to what I wanted before I made a little Boo-Boo, So in today's post I am going to have a quick look at Moose and its Coercion abilities. One thing about moose Coercion is it works along with Moose Types so you can't have one without the other.

Right now we have this

has View => (
is => 'rw',
isa => 'Object',

Which is fine but there is noting stopping my from entering any type of object in there so…

Little Moose Goof

Well in my last post I made a little boo-boo. Well a few really. I wanted to get rid of my 'View' class as it was the same as my 'Element' class once I stripped out some parts. Unfortunately I discovered that I have to add in a number of other attributes to my 'Element' class which should never be part of the 'View' class. So I am going to backtrack on taking View out and put it back in.

Now my second boo-boo from my last post, I wanted to have first letter upper case names for my Accessor attributes…

Going Around Again

If you have been following along you may remember this post, in which I introduced what my API was going to look like. Up till now I had only a few of the basic parts of that list in the in jsut for quick testing. Now before I add in these new elements into my code I think it is time to review my and see how I can clean it up before I add the others.

So I started with the 'View' and 'Element'…

More Noise From the Play Pen

Well in today’s playpen I am going to carry on from my last post and get my new name-space all in order so it looks like a re-factor day today. Some of you may of noticed good number of places where I could use all sorts of Moose goodies to save my self time and typing. For example I could create number of roles for the common attributes across my classes or maybe coercion on some of my attributes. Now might seem like a good time to do that.

Well what I have discovered over the years, and some …

Today in the Play pen

So today's romp in the playpen I think it is time I picked a name-space and stuck to it!

Well after much snooping about and pondering on my part I and going to try to stick my DA in the 'Database' name-space.

That was actually the easy part was the above the tricky bit is figuring out want goes under it, as something like this DA::SQL->new() is what programers want rather than a rather long winded Database::Accessor::Driver::SQL::Connector->new();

So what to do?

Well the first thing is to come up with a clean name-space statement so here is …

Pommie Christmass


Now to circle back again. You may re…

Make and Choice be it bad or good

So the time has come to pick which of the thee patterns I am going to choose to carry on. So here is how I evaluated each one giving advantages first.

Pure Moose;
Accomplished all system requirements, loaded and ran fast, required the least number of external modules, code easy to implement by LSD writers.

Requires the use of 'Klugeish' code son the DA side. The call '$class->new' can be confusing to some as this appears to be some sort of majik var. Options available on the interface are limited.

Accomplished all syst…

The Speed of Moose

So now that that I have three prototypes out there for DA

  • Pure Moose

  • MooseX::Scaffold and

  • MooseX::ShortCut::BuildInstance

  • The question becomes which one to to choose. They all do what I want them to enforce my API , keep the LSD code from beading into the DA code and all allow me now enter just a connection object and the correct LSD will be loaded.

    One thing to do is run some benchmark test to see how fast the various scripts load and then run. I might not matter at this early stage bu I could see that the …

    .9999% Pure Moose.

    Now I do have a working version of the MooseXs Scaffold and Shortcut and even built out the Shortcut version to not hard-code the LSD classes I might have to load. Now what I do not have a pure Moose version so I think I will stub that out now using what I have learned form the other Modules.

    Now it really did not take much time or effort to make this a pure Moose mod. All I had to to was make some adjustments BUILD like this

    – grep { -d $_ } map { File::Spec->cat…

    More Than one Way to Load a Moose

    So from my last post I had to figure out a way to enforce these four rules

    1. All LSD files will be in the DA::LSD name-space or folder if you like
    2. Each DSL has to express which type of driver it expects
    3. Only DSL 'pm' files will be loaded
    4. The loaded DSLs should be cached as loading or at least requiring them may take some time.
    The first question is where to do this in the code. Fortunately Moose has a BUILD sub which is the prefect place for this. So we will start…

    ᒨᓴ ᐊᔅᐗᔨᑕ

    One thing I have neglected till this time was how to Load in my LSD classes. Up till now, for testing purposes, I have been always hard-codeing my Mongo and SQL LSDs in my code, and it did not matter if they where a Role like this
    apply_all_roles( $self, "DA::LSD::SQL");

    or a class such as this

    use DA_S::LSD::Mongo;
    $lsd = DA_S::LSD::Mongo->new(elements=>$self->elements,view=>$self->view);

    in the long run I will have have to have some …

    And one more for luck

    For today's MooseX I was having a look at  MooseX::ShortCut::BuildInstance which was one of the last ones on my initial list.

    So this MooseX required me to almost as much jigging about as in my last post and I had a few false starts on it implementation as the documentation is sparse as are examples, but none the less I did manage to get something up and running in my DA.

    So …

    And the Winner is? (well maybe anyway)

    Today I started taking a closer look at MooseX::RelatedClasses to see if that could help me out. Well after reading though the documentation and looking at the test files to see how it really works I do not think I need this MooseX at all as it really is just for coordinating name-spaces, So I will move onto the next one for today and that is MooseX::Scaffold

    This one does look promising as I can use one common sub to load in my LSDs when one of the DA CRUD commands…

    Moose Relations

    So after yesterdays re-loadfest of getting all my win- registry in order, downloading the latest Strawberry perl, upgrading Moose and getting all the other perls in a row. I tried to work on my DA again and got

    Class::MOP::load_class is deprecated at C:/Dwimperl/perl/site/lib/Class/ line 69

    yet agin.

    Well this time I took the time to look at the rather shortened message, only about 15 lines compared to about 120+ for the first time I tired these new MooseXes so at least some things have been fixed up.


    No News today

    Well today’s blog was suppose to be me looking at some of the MooseXs I reviewed the other day. However I seems that Moose has moved quite foreword since the last time I did a new install and it seems I was getting 'Class::MOP::load_class is deprecated' in almost every thing I wanted to play with.

    Well had a quick look at my Moose version was quite out of date. I had 2.06 or alike and I see now there is a shiny new 2.2009 release that is less than a month old so in that goes.

    Well with the regular rigamarole I tried to reinstall my Moose and it crashed then my Padre stopp…

    Searching for Mrs X

    So yesterday I muddled myself up quite well, so It took a little time to see if I could come up with a solution. Thinking that someone else might have had the same problem I did a troll of Map of CPAN looking for a MooseX that might help me out.

    Now I was looking at briefly at one point of using a delegated object but the problems with that is I contaminated my parent object with unneeded code and I would also have to it…

    Well that's not it!!

    So lets see how I am going to move those annoying 'sub SQL' that I have in my DA::View and DA::Element packages out of them and into my LSDs.

    So going blindly where I have gone before though the I might Role for the Element class in DA::LSD::SQL and see what I can come up with. So I duly added this

    use Moose::Role;
    sub retrieve {
    my $self = shift;
    if ( $self->alias() ) {

    And now for Tea

    Now in my last post I left off with a bit of a code mess. Roles bleeding code into each other and my API in a dreadful state.

    Well on thing I have seen before in non moose apps was use something called 'Class::Rebless' to rip the 'DA::LSDs' from my DA class but that is sort of an abuse of that code as it really is just for renaming name-space and I am not sure it will do what I want.

    I had a look about the Moose::MO…

    Never Role Twice!

    Well did a little more playing about with my applied roles on my and added in a bunch more testing to see if things where working for me.

    First I wanted to see if using a role twice caused any ill effects so I added

    $address->retrieve( 'DBH', $result ) eq
    'SELECT street, city, country FROM person AS me',
    'SQL correct'

    $address->retrieve('MONGO') eq
    'db.person.find({},{ street: 1, city: 1, country: 1}',
    "Mongo Query correct"

    Many Sides of Moose!!

    In my last post I did managed to make a little code progress but I still had one major goal to accomplish and that is to make my Data Accessor smart enough that is would know what Driver to use form the connection passed in.

    Well I am glad to say I am now able to do that with this test 02_base.t

    ok 1 - use DA;
    ok 2 - use DA::View;
    ok 3 - use DA::Element;
    ok 4 - Person is a View

    Just a Quick one!

    So spent a little time working on my rough code from my last post and made up a working copy that you can have a look at here.

    It was easy enough to get the SQL part working, after all I have been using such code my Data Accessor for many years now. It also took only a few minutes create a new DA::Mongo class with and an '_execute' function to come up with the query for Mongo.

    With my limited test I get the correct query in SQL/users/byterock/2017/12/index.html

    Code comes and Code goes but the App goes on!

    Well how about some coding today?

    Lets look at the first little bits from my last post the 'View' and 'Element' and I am going to focus in on using it with SQL in this post. So we have this;

    view => 'person',
    elements => [
    { name => 'name' },
    name => 'street',
    view => 'address'
    name => 'country'
    view => 'address'
    name => 'city',

    And the Plot Thickens

    Yesterday I looked at maybe abstracting my API to make it common across a number of Data Accessor Derivers such as SQL and MongoDB and that got me thinking of how I am going to put all the pieces together?

    Now what I would like is the end user to be able to something like this

    my $address_da = SomeDa::Address()->new();
    my $address_hash = {};
    my $dbh = DBI->connect(“DBD::aything”,$uid,$ps);

    Back in API again

    Now onto another problem!

    With present Perl version of my Data Accessor I had only a very small set of common methods, the CRUD ones and add_dynamic_criterion while the DA::SQL brought into the API many methods and attributes that are SQL specific.

    • Table
    • Fields
    • Group_by
    • Where
    • Having
    • ...

    So if one of my evil plans is to make DA work across a number of differing DB platforms it would not be a good thing if for each of the accessor driv…

    And the word for Today is Abstract

    Well lets play with some code today.

    So I spent a little time having a look at MooseX::AbstractMethod and at first glance it look promising as is suppose to allow on to create an Abstract Class. So having a little time I created a little test code and of course a test file.

    The code is simple parent Abstract class that has one sub and one required or abstract sub and then a child class that extends that parent but does not…

    Pretty Patterns All in a Row

    Now that I have things mostly sorted out let's actually do some code or at least some pseudo-code on how I going to make it work.

    I could go the pure Perl route and do the same sort of thing DBI does, an interface then drivers under it following this design pattern

    Did I Forget Something??

    My little API exercise in my last post I noticed that I may be missing an important part of the puzzle and that is some sort of generic connector function.

    The present perl code does have this:

    sub _connect {
       my $self = shift;
       return $self->_dbh()
          if ($self->_dbh());
       my $dbh;
       if ($self->cache_connection()){
          $dbh = DBI->connect_cached($self->data_source,$self->username,$self->password,$self->connect_attr);
       else {

    I'll poke you right in the API!!

    So I have sketched out my test suite lets have a look at the API I am trying to express.

    For me the API is the most important part design. Have a good workable general purpose one it will become a de-facto standard, like DBI, do a very narrow one it will languish in the niche that is was designed for. It has been said many times before, but it bears repeating here, that any API should be

    • Easy to Learn
    • Easy to Use
    • Easy to Extend
    • Consistent and …

    YAPB (Yet Another Planning Blog)

    Well lets see as I am in a testing mode right now lest have a quick look at the's expressed API to see what I should test or at least how I should organize my tests.

    Always start with the basics so I will have


    that will do your basic load checks to see if it will work on the perl that is trying to run it. No need to go into details there.

    As well I will add in a


    And this will test just a little more than load. Perhaps the use of a driver and some basic set a…

    Tick Tack Test

    Well I would not be a very good CPAN programmer if it did not think of a set of tests before I started any project so let take a look at what I have.

    Fortunately for my Data Accessor (still haven't come up with a new name for it) I have inherited a rather large test suite of about 200+ tests. Unfortunately for my Data Accessor I have inherited a rather large test suite.

    Lets have a look at one

    use Test::More;
    plan tests => 5;


    About byterock

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