January 2018 Archives

Less Moose more Elk

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…

Moose on the edge

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 …

Can a Moose Juggle?

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

Late Night Moose

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 …

More Than One?

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…

The Moose Collective

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


It will begin to break-down my API as a programmer could come along and enter a very specific Mongo item such as 'mergeObjects' or something odd from an SQL DB like 'DENSERANK' and that makes for a very inconstant API.…

A Few Moose Never Hurt

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

Cool Moose

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…

Moose Attributes Cheeper by the Doz

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


That was easy enough just a quick copy and rename job of the Predicate class without its attributes, so six more classes like this one

package
Database…

Two Moose at Play

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

The Many Roles a Moose Can Play

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,

Just a little More 2.

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 ="http://blogs.perl.org/users/b…

Just a Little 1.

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:…

Moose Retest 2.5

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…

Moose At Work

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…

Moose Test 9-5

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…

Even More Moosey

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 …

Building Blocks of Moose

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…

Simple Clean Moose

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…

About byterock

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