Call for Presenters TPCiSLC 2018

Talk submissions for #TPCiSLC are currently being accepted! Round 1 closing/Round 2 opening Jan 28/29.

We will be accepting proposals for the following session types:

Short Talks (20 minutes)
Standard Talks (50 minutes)
Tutorial Sessions (80 or 110 minutes)

To submit proposals for a talk/presentation, please fill out this form: https://goo.gl/forms/2qxdfgtRsdc6lXBZ2.

We encourage you to submit your talk as early as possible. We will be choosing speakers in an ongoing process, with the final submissions to be accepted no later than March 18th, 2018.

Round 1: January 1st - January 28th, speakers notified by 2/7/18
Round 2: January 29th - February 25th, speakers notified by 3/7/18
Round 3: February 26th - March 18th, speakers notified by 3/28/18
Final Speaker Lineup Announced: April 1st, 2018

Apply at https://goo.gl/forms/2qxdfgtRsdc6lXBZ2

More information at https://perlconference.us/tpc-2018-slc/cfp/

Not a Mousse Moose!

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 after some playing about I saw the errors of my ways. Looking at the Database::Accessor::Condition class I remembered to load that properly I will have to pass in any conditions with the 'predicates' param. So I modified my$$in_hash to this;

 conditions=>[{predicates=>[{left=>{name=>'last_name',
                                    view=>'People'},
                             right=>{ param=>'test'},
                             operator=>'='
                             },
                             {condition=>'AND',
                                   left=>{name=>'first_name',
                                          view=>'People'},
                                  right=>{ param=>'test'},
                               operator=>'='}]}],
I ran my test again but then I was back at square one again?
Attribute (name) is required at C:\Dwimperl\perl\site\lib\Moose\Object.pm line 24 Moose::Object::new('Database::Accessor::Element', 'param', 'test') called at D:\GitHub\database-accessor\lib\Database\Accessor\Types.pm line 29
Hmm... So it looks like it does not like my 'param' coercion again. I double checked my 'Database::Accessor::Predicate' class and saw that I had

Just A Cute Moose

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 opening myself up to going down all sorts of test rabbit holes where there is nothing wrong with my Accessor but a problem in my Tests DAD. So what to do?

Well lets have a look at what I have to test:

  • coercion from a hash to a type works correctly
  • class attribute values passed into the DAD are correct

Best Moose Opening Line Ever

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' },
                             { name => 'user_id',
                                view =>'People' } ],
        conditions=>[{ left=>{name=>'user_id',
                               view=>'People'},
                               operator=>'=',
                               right=>{param=>'test'}},
                               { condition=>'AND',
                                   left=>{name=>'first_name',
                                             view=>'People'},
                                  operator=>'=',
                                 right=>{param=>'John'}},  ]
    }
);
which in SQL is

SELECT People.first_name,People.last_name, People.user_id 
  FROM People
 WHERE  People.user_id = 'test'
   AND  People.first_name = 'John'
and Mongo something like this

  db.People.find({$and: [{user_id: {$eq: test}},{user_id: {$eq: John}}]},{ street: 1, city: 1, country: 1}
Not I do not have a working Mongo or SQL DAD right not so the above are just for show so I have to use my fudged results from my last post with my Test::DAD. So I am looking to get this

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

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, like this

   has open_parentheses => (
      is  => 'rw',
      isa => 'Bool',
      default => 0,
      alias    => [qw(open open_paren)]
    );

    has close_ parentheses  => (
      is  => 'rw',
      isa => 'Bool',
      default => 0,
      alias    => [qw(close close_paren)]
    );

Long Live Perl 5!

You probably have read a recent Open Letter to the Perl Community. The letter has generated a lot of response (173 reddit comments as I write this). Unfortunately, a lot of the responses are quite negative and do not match my understanding of the letter.

I figured I share my interpretation of the words and if that interpretation does not match the author's intent, I hope my interpretation captures the mood of the community on the matter.

A Radical Idea

The first thing the letter talks about is what it calls a "radical idea". The suggestion is for Perl 5 compiler to upgrade its backend. Instead of the current Perl VM the perl compiler uses, it would be ported to NQP compiler toolkit and will support all of the backends NQP supports, which currently is MoarVM, as the leading option, with JVM and JavaScript backends at various stages of completion as alternatives.

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 to the Mongo DAD writer to come up with that one.

Like 'Gather' this is just an array of predicates or the same as my 'Condition' class so I can just drop that one and its tests as well. So that is two classes I do not really need.

The Perl Conference in Salt Lake City, 2018

We are pleased to FINALLY bring you the news everyone has been waiting for!

It is with great enthusiasm that we happily announce The Perl Conference in North America, 2018 will be held Sunday, June 17th through Friday, June 22nd at the Little America Hotel in Salt Lake City, Utah!

The main event will run from Monday, June 18th through Wednesday, June 20th. Master Classes, training, and other activities will be held on the 17th, 21st, and 22nd. We highly encourage you to attend all days, but especially look forward to seeing you at the Main Event.

This year’s website is already live and can be found at https://perlconference.us/tpc-2018-slc/.

Call for Participation is live at https://goo.gl/forms/PkYHWD3B4vUKZLrW2. Please consider submitting a talk!

Registration will also be live February 1st, so watch out for that!

Keep watching for additional announcements.

#TPCiSLC

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

{
    package Database::Accessor::Roles::PredicateArray;
    BEGIN {
        $Database::Accessor::Roles::PredicateArray = "0.01";
    }
    use Moose::Role;
    use MooseX::Aliases;
    
    has predicates => (
        traits  => ['Array'],
        is      => 'rw',
        isa     => 'ArrayRefofPredicates',
        coerce  => 1,
        alias   => 'conditions',
        handles => {
            _add_predicate   => 'push',
            count_predicates => 'count',
        },
    );
1;
}
and in my Condition class I just add in the role

    with qw(Database::Accessor::Roles::Alias
++             Database::Accessor::Roles::PredicateArray
    );

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     => 'ArrayRefofPredicates',
        coerce  => 1,
        alias   => 'conditions',
        traits  => ['Array'],
         handles => {
            add_predicate   => 'push',
            count_predicates => 'count',
        },
    );

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' would be my 'param' and I would pass it as a scalar value. Now I would hope the person writing my DAD SQL write would do it like above and not like this

sub some_sql{
     my ($in) = @_;
     my $sql =  'SELECT * FROM person where person.id=$in';
     my $sth -= $dbh->prepare($sql);
     my $person =   $sth->execute();
    ...
 
I would not like to see that JAVA SQL-Injection attack

Simple (Date) Range Overlap Detection

I started down this particular rabbit hole when (a) I had to check for date range overlaps when worrying about scheduling appraisals; and (b) my attempts to use SQL BETWEEN resulted in complicated, hard-to-read SQL.

Now you would think that BETWEEN should give you easy-to-understand SQL for date ranges. Maybe in the hands of others BETWEEN does, but for me by the time I accounted for all of the cases the BETWEEN-based SQL date range overlap detection got more complicated than I thought it needed to be. So I drew up some diagrams, which eventually led me to the realization that this:

dateA.start <= dateB.end
        AND
dateB.start <= dateA.end

is all that you need. No BETWEEN needed, simple to read, and should work in any useful dialect of SQL.

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.

So I am just going to bite the bullet and add in a 'Type' for this attribute so lets have a look at that.

Well to start I will have to narrow down what I want aggregate to mean. In Mongo it is a command word with some thirty+ operators and in SQL, depending on the DB, as few as five to many more than Mongo. So after a few hours of reading and revising I came up with this short list;

A Simple Telegram Bot

I just wrote a small post A Simple Telegram Bot in my blog... with a tiny introduction to Bot::ChatBots::Telegram. Comments more than welcome!

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

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 am going to start filling in the attributes of my various embedded Database::Accessor classes and I guess the best place to start in with Database::Accessor::View.

Abusing Multiple Dispatch in Perl 6 for fun and profit

Abusing Multiple Dispatch Creatively is avallable on my blog for perusal. Comments and questions welcome as always.

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::Accessor::Param;
    use Moose;
    with qw(Database::Accessor::Roles::Base);
     has '+name' => ( required => 0 );
1;
Now I quickly realized I should update my Roles a little seems that

 has '+name' => ( required => 0 );
is reused seven times. Thinking one step ahead again, in SQL there are really only three SQL clauses that would use an alias so that makes to take that required out the base and have in only on the ones with alias. So in 'Database::Accessor::Roles::Base' I do this

--  required => 1,
in my View, Element and Filter classes I add in

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',
        isa => 'Str'
    );
Now the above is fine for my View and Element Database::Accessor classes but the above sort of breaks down when I have a look a the 'Database::Accessor::Predicate' class. Now it is always good to have a class to have a 'name', makes debugging a little easier, but is the name required in this Class. Thinking a few jumps ahead when when I go to write my say my SQL DAD I can not see much use for requiring a name in a predicateand I cannot think of any case where I will need an 'alias' so to do this;

 package 
           Database::Accessor::Predicate;
    use Moose;
    with qw(Database::Accessor::Roles::Base);

Perl 5 Porters Mailing List Summary: January 2nd-9th

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week.

Enjoy!

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.