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 come back to haunt me. So the main use of this class is a way to provide data to your Accessors so you can do data queries on the fly.

Not 100% sure how this works in Mongo land but I suppose it is much the same but that is for a much later post.

Now I really do not have much to add to this Class just


has value => (
is => 'rw',
isa => 'Str|Undef|ArrayRef',
alias => 'param'
);

Now you will see some need Moose stuff in the above with the 'isa'. I am telling Moose that this Attribute can be any one of three types String, Undef and and Array Ref. Now I puzzled over this for a while I went with the most basic set.

'String' will cover off any Scalar be it numeric or not and it is up to the DAD designer to figure out what to do in the case there is something special handling for numeric values or special characters.

Undef is important for two reasons as in most Dbs there is a difference between NULL and empty. So a text field can be NULL or '' (an empty string) letting my users pass undef into an Accessor this way will allow for this slight difference.

ArrayRef I have added for now as there are many time in SQL and Mongo that you might be entering an array of values such as with an 'IN' select in SQL or say the options param on Mongo.

Now you will also notice I added in


alias=>'param'

Well to get this to work I need to add in 'use MooseX::Aliases;' at the top of the class

package Database::Accessor::Param;
use Moose;
with qw(Database::Accessor::Roles::Base);
++ use MooseX::Aliases;

and a quick test change in 16_param.t

--my $param = Database::Accessor::Param->new({name=>'right'});
++my $param = Database::Accessor::Param->new({name=>'right',param=>22});
...
++ok($param->value() == 22,'Value = 22');
++ok($param->param() == 22,'param = 22');

and I get

ok 5 - Value = 22 ok 6 - param = 22

Now you might ask why do this. Well it lets me open my API up to things where I can different accessors for the same data but more on that much later.

I will give you one quick example of how this little MosseX saved my arse. Some time back we had an existing API web site all set for UK postal codes like K1J... etc then as the fates would have it, we had to munge it for the US market where they have zip-codes. Well instead of rewriting many dozens of pages to take both ZIP and PC all I did was one or two quick changes to add in the alias 'ZIP' and saved goodness knows how much time. I will know better next time as we where being paid by the hour and the client was fully willing to pay for the 30 days of re-code, I guess I should of never spoke up during that meeting with the client.

Now onto other things.
Spikegate.jpg

Leave a comment

About byterock

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