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

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!

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.

prepare_inline

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.

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.

http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html

David Nicol <davidnico@cpan.org<gt>

Copyright (C) 2008 by David Nicol

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.