After noticing the syntax I've written a module that handles
the process. Before putting it on CPAN I'd like to get opinons
on the interface. The point is to avoid all of the
bind_param_inout setup by creating some per-handle metadata
with the bound array and fields to copy in from @_, out to
the caller. After that the caller only sees a prep step and
the execute calls.
One approach uses classes derived from DBI and DBI::st to
add "prepare_bound" to DBI and "execute" to DBI::st. The
resulting code looks somethingn like:
my $dbh = blah;
my $sql =
q{
insert into
table ( ... )
values ( ?, ?, ?, ?)
returning idfield into ?
};
my $sth = $dbh->prepare_bound( $sql );
...
my $id = $sth->execute( @insert_values );
or
my @id = $sth->execute( @insert_values );
This seems nice in that the syntax for prepare (and
prepare_bound_cached) look rather DBI-ish.
Catch is that this makes deriving other classes and
using statement handles from oddly-derived classes
somewhat tricky.
Another approach is simply adding a post-processing
step to the statement handle:
my $dbh = blah;
my $sth = $dbh->prepare( $sql );
$sth->binderize( $sql );
my $id = $sth->execute_bound( @insert_values );
The downside here is extra steps to binderize the
handle and a separate execute command -- which
might interfere with the statement handle if
accidentally mixed with $sth->execute.
Personally, I'm leaning towards the first technique
even if the internals are a bit messier: NEXT makes
re-dispatching the execute and prepare steps
manageable and the syntax seems cleaner.
Any suggestions?
--
Steven Lembark 85-09 90th St.
Workhorse Computing Woodhaven, NY 11421
[EMAIL PROTECTED] 1 888 359 3508
