In part 11 we had a look at a look at getting values back from SPs (stored procedures) now we are going to look a another variation on binding the array_execute.
One of Those Days
You know what its like. You have just been handed a requirement to store 200 individual selections from a web page. Well as a diligent programer with you now epic DBI skills you come up with this
my $sth = $dbh->prepare("INSERT INTO picks (user_id, pick_id) VALUES(:p_user_id, :p_pick_id)");
for (my $index=0;$index
$sth->bind_param(':p_user_id', $user_id);
$sth->bind_param(':p_pick_id', $picks[$index]);
$sth->execute();
}
Well at least you know it works but you may be sucking up a good deal or resources with an execute at each iteration and bind as well any error along the line could cause all the data sent to the DB to be lost.
During test writing often I find myself having to use a lot of modules and setting up various things that should be common for all of my tests in a given project. In some examples it may get ugly and I really don't like having a ~30 lines long setup in every single test file of mine. After some experimenting, I came up with a quick-and-dirty solution. I create a module in my 't' directory (let's say t/lib/Test/MyApp.pm) and put everything I need into it's import sub:
When I previously blogged about Test::Class::MOP, I showed the bare basics of a test. Per a suggestion from Toby Inkster, I've now added an is testcase trait for methods. Unlike Test::Class::Moose, test methods no longer need to start with test_. Instead, you can do something like this:
method simple_test($report) is testcase {
$report->plan(1);
is $self->test_fixture->full_name, 'Bob Dobbs',
'Our full name should be correct';
}
Obviously there's a lot going on there, so I'll explain a bit more about this.
In part 10 we had a look at a look at the $sth 'bind_param_inout' method to get something extra from an DBI query. This time we will stick with this but look at another common use at was hinted at in the last post.
Store This!!
Unlike many perl programmers I think SPs are a great. The encapsulate biz-rules really well, in the old days they ran faster, are easier to maintain and they can protect you when the Boss tells you we want to move over to 'Elixir' front end with a 'D' back end.
Calling all Cars
Calling an SP with DBI is quiet strait forward, though implementation is different between RDBMS languages. Some require some sort keyword others only let you run an SP inside their own procedural language.
I wrote up a blog entry about typeglobs on my personal blog: what they are, and what they are used for. If you've never heard of typeglobs, or you feel you could stand to pick up a trick or two, check out the post:
I needed this when I encountered a page where the forms moved around based on whether you logged in as an ordinary user or an administrator. (Not my page, so don't blame me :( .)
This past May, The Perl Foundation awarded a grant to fund development of a couple features in Pinto. Pinto is a robust tool for curating a private repository of CPAN modules, so you can build your application with the right modules every time. This is my third progress report on that work.
I've been preoccupied with Stratopan lately, so I have no progress to report this month. But now that the beta has been launched, I expect to have more time for grant work.
By the way, if you sign up for the Stratopan beta before December 15, you'll get unlimited access for life.
In part 9 we had a look at ASIC transactions as implemented by DBI now we are going to have a look at getting more back from DBD $sth than just the rows updated or the the record set.
Look Ma no Hands
There are many times when playing with RDBS that we would like to get just a little more back form the DB when we do something. What comes to mind first of is those nasty primary_key values after we do an insert. Most if not all RDBS have some way to get them back at least in the SQL world but how do I do this in DBI.
bind_param_inout
Well the answer is to use the SQL and the bind_param_inout method to get value from the DB. Most mainstream DBD do work I will just use DBD::Oracle as I have the code handy.
Hello everyone, this is my first post here.
I'm fairly new to Perl (~1 year experience) and to testing. I'd like to write not so much articles, but short, to the point code snippets with comments that are useful for those, who are new to Perl, DBIx::Class, PerlDancer2 and testing.
I will try to post things that I would like to know when I started out, but could not find them.
Stevan Little has been asking people to port things to the p5-mop-redux or to create new modules. I decided to reimplement Test::Class::Moose as Test::Class::MOP. The following works:
In part 8 we used fetchall_arrayref to get just the fields we want and not the entire row now we will looks at when we make mistakes.
DBI Transactions
In a perfect world, we would never need our old friends commit and rollback. But hard disks die, the power goes out, and fingers click the wrong buttons; so DBI supports the age-old ACID Module for transactions. As long as the underlying DBD driver and RDBMS and Driver support it as well.
To get transactions to work on DBI, you first have to set the AutoCommit attribute of our database handle to off. One normally does this when creating the handle like this:
Timm Murray will show you how to get started writing Perl apps for Raspberry Pi. He’s built a rover using Raspberry Pi and Perl, which controls an Arduino for motor controls.
These will print something like this, which helps understand the content of the variables, but shows only a generic variable name such as $VAR1 and $VAR2.
Your all excited you spent 3 months of your own special free time working on your first CPAN package.
You spent so many hours on an IRC discussing how it should work your spouse suspects your getting a bit on the side.
You included a test suite of over 500 tests,
You put blood, sweat and tears into the Makefile.PL so it will load on any perl on any platform.
If you see one more comment on prepan from that son of a jerk off byterock you're going to punch in in the throat next time you see him at YAPCE:EU
So you clicked the button on PAUSE and had to endure that wait, while PAUSE does it thing. So you go to bed and sleep soundly knowing that by morning my code will be up on CPAN.
You jump out of bed with the anticipation of a six year old on Christmas morning only
to see this
(Posted here so I don't forget it and others can find it...)
In the latest DataCite Metadata Kernel document, section "2.2 Citation", DataCite recommends ("prefers" is their term) that original-format DOIs used in citations include the doi: scheme prefix. ("Original format" refers to non-URL DOIs.) Unfortunately, the DataCite Metadata Kernel document does not mention that the string doi: is a scheme prefix, making it hard to find.
An example DOI with the scheme prefix is doi:10.1006/ijhc.1996.0110.
Travis-CI is a Really Useful Engine, but I've only enabled it for a handful of my GitHub repositories because navigating though GitHub's settings to do so is a bit of a pain.
Seemed like this should be scriptable though - turns out it is! Edit that script to include your GitHub login details, and Travis-CI details, save it as travis-status somewhere in your $PATH, chmod +x travis-status and you're ready to go!
Running travis-status in a project's root directory (and I'm assuming the project's root directory has the same name as the repository's slug) with no parameters will print out a list of all event hooks for the project (not just Travis ones). Running it and passing "1" or "0" as the parameter will enable or disable Travis for the project.