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-2011 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.005 or, at your option, any later version of Perl 5 you may have available.