NAME
DBIx::InterpolationBinding - Perl extension for turning perl double-quote string interpolation into DBI bind parameters.
SYNOPSIS
my $dbh = DBI->connect(...);
{
use DBIx::InterpolationBinding;
my $sth = $dbh->execute("SELECT * FROM table WHERE id=$id");
}
my $result = $sth->fetchrow_hashref();
DESCRIPTION
DBIx::InterpolationBinding uses the magic of Perl 5's constant overloading to cause interpolation into strings to be treated as though the values being interpolated were used as bind parameters.
Because of limitations in the way in which this module works, it is typically better to keep this module in force for the minimum amount of code, as in the above example. For an in-depth discussion of bugs, see the BUGS section below.
EXPORT
$dbh->execute($sql);
Rather rudely, this module exports an execute method into class DBI::db, so you can call execute() on DBI database handles.
This method only accepts overloaded strings (ie. those created when DBIx::InterpolationBinding is in force) - this makes it harder to shoot yourself in the foot by using it with strings that have been interpolated in an unsafe way.
Returns a DBI statement handle, or undef on failure.
$DBIx::InterpolationBinding::DEBUG
Set this to 1 (default 0) to see the statement being prepared and the bind parameters passed to DBI.
BUGS
Because of limitations in the way Perl 5's overloading interacts with this module, the limitations below may apply. Some of these are fairly major, so you may wish to take care.
- You cannot build up SQL through interpolation
-
The system doesn't know which bits are SQL and which are bind variables. The following doesn't work as expected:
$dbh->execute("SELECT * FROM table WHERE id=$id $where_clause");
You need to build it outside the scope of DBIx::InterpolationBinding in this case, using conventional bind params.
- String passed in from outside the lexical scope will not have been overloaded
-
If the string passed in is to be interpolated or concatenated into a string in the lexical scope this is fine, but if a string from outside is a bit of SQL the effects may be curious.
- Trying to concat (. operator) an overloaded object with a string created in scope may have unexpected effects.
-
This is because the strings in scope are actually objects with an overloaded concat operator. The overloaded function you're expecting may not be the one you get!
SEE ALSO
SQL::Interpolate::Filter achieves a similar thing using source filters. I wanted to write a solution which didn't use source filters because of the difficulty in writing filters which can correctly handle all Perl syntax without incorrectly modifying the code. I also personally prefer my syntax.
AUTHOR
Luke Ross, <luke@lukeross.name>
COPYRIGHT AND LICENSE
Copyright (C) 2006-2008 by Luke Ross
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.5 or, at your option, any later version of Perl 5 you may have available.