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.
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.
David Nicol <email@example.com<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.