roman has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

reinventing the wheel, I wrote another module trying to keep together arbitrary chunks of SQL text with bound parameter values. Or - in other words - trying to bind params in statement before the statement is passed to database. (I know there are other modules doing similar thing in different manner, as are SQL::Interp and SQL::String). I want to upload my module to CPAN and looking for an appropriate name:

According to synopsis below What is the most apt replacement of original - my company's proprietary - name Akar::DBI::Statement?

I used DBIx::AbstractStatement 2 years ago, but the concept changed and I don't like it anymore.

Please tell me also, if there is a more appropriate place to ask such questions.

Thanks

Extract from Synopsis
use Akar::DBI::Statement qw(sql sql_in sql_param sql_param_inout); my $start_date = '2007-06-01'; my $statement = "SELECT id, filetype, filesource_name" . "\nFROM manggis.files " . "\nWHERE filetype IN ". sql_in( qw(durian durianloader_in durian +loader_out) ) . "\n AND state IN ". sql_in('f', 'F') . "\n AND created > to_date(". sql_param($start_date ). ", 'YYYY- +MM-DD')"; my ( $text, $values_ref ) = $statement->text_and_values;

Yields:

# text: 'SELECT id, filetype, filesource_name FROM manggis.files WHERE filetype IN (?, ?, ?) AND state IN (?, ?) AND created > to_date(?, \'YYYY-MM-DD\')' # values_ref is [ 'durian', 'durianloader_in', 'durianloader_out', 'f', 'F', '2007 +-06-01' ]

The statement may be further interpolated with predictable results

my $cnt_statement = "SELECT count(*) FROM ($statement)";

with Interpolation the code is cleaner

use Interpolation 'sqlp' => sub { sql_param(@_) }, 'E' => 'eval'; $statement = <<"END_SELECT"; SELECT id, filetype, filesource_name FROM manggis.files WHERE filetype IN $E{ sql_in( qw(durian durianloader_in durianload +er_out) ) } AND state IN $E{ sql_in('f', 'F') } AND created > to_date( $sqlp{ $start_date } , 'YYYY-MM-DD'); END_SELECT

You can bind inout parameters as well:

my $retval; my $statement = <<"END_PSQL"; BEGIN manggis.create_new_file( 'filetype' => $E{ sql_param($filetype) }, 'file_id' => $E{ sql_param_inout(\$retval, 40) }, ); END; END_PSQL

The statement may be passed to dbh in different ways

$dbh->selectrow_array($statement->text_attr_values); $statement->prepare_and_bind_on($dbh);

Or even (when you modify your dbh class) you don't need to distinguish between text and statement at all

my @row = $dbh->selectrow_array($statement_or_text); my $sth = $dbh->prepare($statement_or_text);

You can even bind the params "tradionally".

my $statement2 = sql('SELECT * FROM manggis.files WHERE state = :state +'); $statement2->bind_param(':state', 'F');

Replies are listed 'Best First'.
Re: The name for another SQL text with bound values module
by CountZero (Bishop) on Sep 14, 2007 at 18:59 UTC
    Definitely something in the SQL:: namespace.

    Perhaps SQL::Vault as a place where you can safely store your SQL snippets?

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: The name for another SQL text with bound values module
by jZed (Prior) on Sep 15, 2007 at 14:14 UTC

    Personally I think SQL::* should be for modules that are primarily about SQL (e.g. SQL::Translator and SQL::Statement which can be used to work with SQL quite apart from DBI) and may secondarily have a DBI tie-in, whereas DBIx::* is for modules (like yours) that are primarily extensions to DBI and really do not deal at all with SQL except in a DBI context. But others have long ago blurred that line so at this point, I'm not sure it makes a difference.

    The main thing I suggest you aim for in your title and in your POD is a clear description of why someone would want to use this module instead of SQL::Abstract or SQL::Interp or one of the other existing alternatives. Dont denigrate the others, just give a fair comparison of where yours has strengths. Is your module to be used instead of the others or in addition to the others? If the former, why should anyone switch? If the latter, in what cases is it needed?