December 2017 Archives

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