NAME

DBIx::bind_param_inline - list variables in $dbh->prepare method instead of calling $sth->bind_param

SYNOPSIS

Syntactic sugar allowing implied statement parameters, like in SQR.

  use DBI;
  ...
  use DBIx::bind_param_inline;
  our ($foo, $bar, $baz); # MUST be "our" not "my"
  # qq style -- escape rods of Asclepius
  my $sth = prepare_inline($dbh, <<SQL);
  SELECT * from mytable WHERE foo = \$foo AND bar = \$bar AND baz = \$baz
  SQL
  # q style -- noninterpolative
  my $sth2 = prepare_inline($dbh, <<'SQL');
  INSERT INTO mytable (foo, bar, baz) VALUES ($foo, $bar, ? )
  SQL
  ...
  $sth->execute(); #placeholders get bound for you
  $sth2->execute($something->compute_baz); # regular placeholders still work!

DESCRIPTION

prepare_inline identifies inlined variables and replaces them with ? placeholders before calling the normal prepare. The resulting statement handle has some additional information in it so bind_param will be called when it is executed, and all other methods called on it fall through to the non-extended statement handle.

The important thing is, you get to name your variables directly within your SQL, which means less counting question marks and more freedom to change the order of things.

So we get to trade the tricky action-at-a-distance problem of placeholder order for the more manageable action-at-a-distance problem of package variables.

EXPORT

prepare_inline

HISTORY

0.03 2009 April 29: Changed from NullP to SQLite for testing purposes, actually creating a table and accessing it with this new syntax. This tool actually works now.

BUGS

Doesn't work with lexical my variables. I believe this could be repaired by walking the pad instead of or in addition to looking at caller()."::$name". Patches welcome.

AUTHOR

David Nicol <davidnico@cpan.org<gt>

COPYRIGHT AND LICENSE

your choice of GPL 2, GPL 3, or AL. Did I actually reserve any rights for myself? Yes, I did. You're not allowed to lie and say you wrote it.

CPAN RT