For my Moose-pen today I am going to have to put my thinking moose and get out of my class, type, attribute and coercion rut that I have been and and look at how my Accessor will be used by other programmers.

Fortunetly I have not done a good deal of work in this area. So far I have only the retrieve and my 'BUILD' sub that I use to load in the DAD that might be out test. Now this is where I am getting into problems as the way it stands not thing will work fine with static Accessor but I will have problems with adding in dynamic attributes.

To illustrate this lets start w…

Just a short note for the Moose-Pen toady, I am going to clean finish off my Moose droppings by looking at the Expression.

Well all I really have to do is do a search and replace on the word function in my last post and and then past is here but that would be cheating. If I did do that I would at least see if anyone is reading these apart from Gabor.

So I will be working the 14_predicate.t and adding in the following;

="prettyprint…

Today in the Moose-Pen I am going to cleanup up more Moose droppings. Now I already added in the Function and Expression class and came up with a few modest tests case for them '19_function_expression.t'.

Not that is fine and good for a unit test on that class but the problem is these two classes will never be used as stand alone classes they will always be used inside other objects typically in the same place I would use a Param or Element class and most of the time in a Predicate o…

Today in the Moose-Pen I am going to look at something new 'Native Delegations' on attributes or to say it another less wordy way 'Traits'

Native Delegation is a way to let you treat standard Perl data structure as if they where objects. So to take an example from my test cases say you have this

foreach my $index2  (0..(scal…

Well more testing and re-factoring with just a little Moose in the Moose-Pen today. So I spend a good deal of time getting my tests cases all in a row. Now just a few interesting details on that, I created a number of generic utility tests that can be reused in my test cases. What I did was take the 'cmp_deeply' test like this on in 33_constants.t
my $da_conditions  = $da->conditions();
   my $dad_conditions = $dad->Conditions();
   m…

Well it clean-up and re-factor day in the Moose-pen. So no new Moose Majick today just cleaning up and adding in stuff that I have left out (forgotten actually) and moving things about.

Well the first thing I did was finish off the last three of my remaining Accessor attibutes, 'gathers', 'filters' and 'sort' or if you are SQL inclined 'group by', 'having'. and 'sorts'.

The 'gathers' and 'sorts' attributes are just a pair of 'ArrayRefofElements' which I covered off in this post and types and…

So today in the Moose-pen I am going to move onto something a little differtn and that is my Accessor 'links' attribute which I am going to cover with the 35_links.t test suite.

I did a quick review of the bits and pieces I had stubbed in so far and I notices I need a few thing. First had a look at my Accessor 'links' attribute and I will need a new type for that. So to get this new 'ArrayRefofLinks' type I just did what we have seen in a number of older posts, namely add in a 'use', a 'class_type…

Today in the Moose-pen I am going to play with the very familiar 33_condtions.t and this time I am going to solve another little API problem I know I am going to run into.

Part of my evil plan is to allow end users to add in conditions on the fly and I have made provision for that with the 'rw' 'conditions' attribute found on my DAD Role. Now I have to fix a minor oversight on my part can change the type on 'conditions' to be the same as the original in Accessors, so I changed this
/users/byterock/2018/01/index.html

Well in today's Moose-pen I am still going to play about with good old 33_condtions.t, not the tests per-say but the API they are calling. In my last post I fixed the my API call by adding in the 'predicates' param to the 'conditions' param like this
...
view =>'People' } ],
conditions=>[{predicates=>[{left=>{name =>'last_name',
view =>'People'},
...

to me the above…

So in my last Moose-pen I ran into problem with my 33_conditions.t test case where it was giving me errors like this

# Compared $data->left
# got : Does not exist
…

Well today in the Moose-pen I am still going to have a look at my 33_conditions.t test case. In my last post I got all the little bits working right up to the point when I want the DAD to return or at least crate this string

RETRIEVE-->View-->'People'-->Elements-->'People.first_name',
'People.last_name','People.user_id'-->Condtion->People.user_id=test-->AND-->
People.first_name=John

After sleeping on it and then playing a bit I came to the very wise conclusion to not to test my Accessor in this way. If I take this path then I am op…

So today in the Moose-Pen I was going to get my 33_conditions.t test case working. New we left off in my last post with this call to Accessor
my $user = Database::Accessor->new(
{
view => {name => 'People'},
elements => [{ name => 'first_name',
view=>'People' },
{ name => 'last_name',
view => 'People' },
/users/byterock/2018/01/index.html

Well back to clean up mode in the old Moose-pen today as I have completed my first round of changes to my Database::Accessor embedded classes. Just taking a quick peed at what might attributes might be missing from my I see that my Predicate is missing something important at least to any logical predicate. That is the ability to add parentheses to a predicate.

Well the way I see it I can just make this a Boolean flag attributes such as 'parentheses' but that takes a good deal of flexibility from the system. So what I am going to go for is two flags one for open and one from close…

Now in the Moose-pen we are coming to the home stretch of my Database::Accessor Classes, starting with 'Gather'. This one represents a fields in an in SQL 'Group by' clause, and in Mongo 'Group' stage.

Looking at it it really is just an array of predicate clauses so I think I can just drop this class altogether, which is always a good thing. So out it goes and the test as well. So that was easy.

Next it 'Filter' which is a 'Having' clause in SQL and I not 100% sure what it is in Mongo most likely something to do with group and project or maybe match? I guess it is up …

The next class in the Moose-pen is Database::Accessor::Link which would represent a 'Join' in SQL and a I think they call it a 'Pipe Lookup' in Mongo or it could mean a find on a document buried under the parent document. I guess that is a topic for a later post.

The first thing I noticed was this class and the 'Condtion' class I looked at yesterday is they share the same 'predicates' attribute. So being a good Mooser the first thing to day is to pull that attribute out and add it into a role.

So after a few copy and pastes and a little typing I have

/users/byterock/2018/01/index.html

In today's Moose-pen we are going to have a look on one of the first my compound Database::Accessor classes 'Database::Accessor::Condition'. By compound I simply mean a class that holds other classes.

The Condition class is just as it sounds a class to add a logical condition to an Accessor. In SQL it would be a 'where' clause and Mongo some of the 'Aggregate' clauses. So basically this is a class that holds a number of 'Predicate' classes. So all I need to add is;

 has predicates => (

        is      => 'rw',

        isa   …

Well today in the Moose-pen I am going to have a look at my Database::Accessor::Parm. Now this is one of the more use full of my classes, This is the one that is used to supply data to a DB query. So in DBI you may have something like this
sub some_sql{
my ($in) = @_;
my $sql = 'SELECT * FROM person where person.id=?'
my $sth -= $dbh->prepare($sql);
my $person = $sth->execute($in);
...

The '?' is replaced with the '4' in the execute. Now in my model that '4' wo…

Well in my last post I added a few new attributes to my Database::Accessor::Element class and when playing about bout today I think I will have to revisit one of them 'aggregate'.

If I just leave it as it is

 has 'aggregate' => (

        is  => 'rw',

        isa => 'Str',

     );

 

So continuing on with the attribute fun today in the Moose-pen I am going to have a look at my 'Element' Database::Accessor class. So far like View there is not much to it only 'alias' and 'name'

Now putting my fore-ward looking Moose glasses you can see that I am going to need some more attributes. Well in SQL this class is being used as a field so I will need at least a 'table name' but then again I do not have a table in Classes so I guess I need a 'View' object now I could do this.

has 'view' => (

        is  => 'rw',

  …

In yesterday's Moose-pen I hinted that I would be getting all my test in order. Well I did that and checked them in but there really was not that much to report on. Just a lot of repetitive code. I suppose I could write one test case to check all of my Database::Accessor classes using some simpler iteration over a list but I really like having a separate test case for all my classes as there really is only a small part that is common between them, so onto something different today.

I…

So today in the Moose-pen I am going to stub in the rest of my Database::Accessor classes and the rest of my Accessor.pm attributes.

It seems I have six outstanting Database::Accessor classes to add in namely;

• Param


• Condition


• Link


• Gather


• Filter


• Sort

 package 

           Database…

So today in the Moose pen I am going to have a closer look at my Role from my last post. So here it is
package Database::Accessor::Roles::Base;
BEGIN {
$Database::Accessor::Roles::DAD::VERSION = "0.01";
}
use Moose::Role;
has 'name' => (
required => 1,
is => 'rw',
isa => 'Str'
);
has 'alias' => (
is => 'rw',/users/byterock/2018/01/index.html

So today in the Moose-pen I was going to move out of the testing mode and actually do a little more coding, well some re-factoring anyway.

One of the best things about re-factoring Moose code is how easy it is to use a Role to stomp out all sort of duplicated code.

So of you may of already spotted s little anti-patter I had going on on most of my Database::Accessor classes and that was the;

 has 'name' => (

        required => 1,

       …

So To carry on from my last short post another short post. I am going to expand and modify my 20_dad_load.t again this time digging a little deeper in Moose's MOP or to give its full name 'Meta-Object Protocol'

One of the things I like most about moose is how easy it is to do “Introspection” or I like to say 'Lets have a look under the hood'. So I have expanded my role test from the other ="https://blogs.perl.org/users/b…

So just a quick one for the Moos-pen today.

I my last post I did create a Test DAD, but then I discovered the problem with doing this is you may spend considerable time just debugging that class to make sure it at least works with any roles it may have to consume and even if you get it to work you may have problems with the roles it is trying to consume.

So I really should test my Database::Accessor::Roles:…

So in today's Moose pen I am going to stick to the testing tree and have a look at my brand new 20_load_dad.t file in my brand new database-accessor repository

Now in past test cases like this, I did a little creative coding and made up a fake test class for SQL and Mongo drivers that where used when I called this

my $fa…

So today in the Moose-pen I am not going to any coding just another of those little planning review sessions one should take when creating a new system.

So for the two-bit review,

• Planned out and amended my basic API
• Settled on the basic architecture
• Done some PoC programming
• Now know where som of the problem area will be.
• Have some workable tests

So my next step was to migrate all my code out from the blog repository up on git-hub and into its own git-hub repository which I have done. I also want to set this up…

So today I am going to follow along from my last post and come up with a little better way to test my Database::Accessor::Roles::DAD role.

This stems from my mistake of the other day of not addng in the 'Collections' attribute to my “Database::Accessor::Roles::DAD” role. Now the purpose of this Role is to supply all the necessary objects from my Accessor.pm down into the various DADs so it is importat that I pass that along.

So I guess my first test is to check that I have my Role in correct shape. A simple use ok will do that, but what I want is a way to test that all my…

Today I am d going to start filling in my API a little and some might remember the table from this post looking at it a second time I think I need to make a few adjustments to this
+-------------------+-----------------+-----------------+
| Data Accessor | SQL | Mongo |
+-------------------+-----------------+-----------------+
| Param | Param | Param |
| Element | Field …

Well for today’s post I am going to continue along with one of the basic building blocks of a good Moose program coercion. We saw in the last post how I started to clean up my interface with coercion and I am going to do that to the next Accessor.pm attribute
has elements => (
isa => 'ArrayRef',
is => 'rw',
);

On one point I ran into while with this attribute was I could make this one into a Hash-Ref of Ele…

So today, to start the new year right, I really am going to have a look at Moose coercion which I have been promissing to do since this post. So to refresh your memory I had created my types role and one type and added it to my accessor like this
has view => (
is => 'rw',
isa => 'View',
);

So what exactly does coercio…