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/Types.pm failed:
Error=Can't locate Database/Accessor/DAD/Types.pm 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…

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

); 

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…

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 Accessor.pm jsut for quick testing. Now before I add in these new elements into my code I think it is time to review my Accessor.pm and see how I can clean it up before I add the others.

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

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 …

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 …

Now to circle back again. You may re…

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.

MooseX::ShortCut::BuildInstance;
Accomplished all syst…

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

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 …

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…

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.

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

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 …

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…

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/MOP.pm 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.

Anywa…

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…

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…

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

 package 

     DA::LSD::SQL_D::Element;

  use Moose::Role;

  sub retrieve {

        my $self = shift;

        if ( $self->alias() ) {

          …

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…

Well did a little more playing about with my applied roles on my DA.pm 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

 

ok(

    $address->retrieve( 'DBH', $result ) eq

      'SELECT  street, city, country FROM person  AS me',

    'SQL correct'

);

ok(
$address->retrieve('MONGO') eq
'db.person.find({},{ street: 1, city: 1, country: 1}',
"Mongo Query correct"
);
/users/byterock/2017/12/index.html

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
/users/byterock/2017/12/index.html

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

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

          v…

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

…

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…

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…

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

…

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 DA.pm 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 {
     …

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 …

Well lets see as I am in a testing mode right now lest have a quick look at the DA.pm'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

00-load.t

As well I will add in a

02-base.t

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

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

 
#!/usr/bin/perl
use Test::More;
plan tests => 5;

  require_ok…