I'll check SQL::Interpolate. Thank you!

It's possible that you're building up your query clauses too early. Why not just build up the "where" hash that SQL::Abstract wants and turn that into your statement and bind variable only just before running the query?

Because my code takes an anonymous closure as a callback, roughly along these lines:

# of course this is just an excerpt of code.
            sub {
                my $caller=shift;
                $rf->execute(substvars(@bind, @_)) or
                  $caller->complain("Error executing this and that.");
                $rf->fetchall_arrayref;
            }
[download]

This is a closure around $rf and @bind. $rf is an object of the class DBIx::ContextualFetch::st.

All in all this is a clean approach that I like. But I don't like the substvars() bit, which IMHO makes it dirty...

You want to predefine a bunch of default values for various slots in @bind, but want to fill the rest in later, right? I.e. you want to curry the bind values, but not necessarily in order? And is your issue with substvars its opacity?

That general goal of defaults plus replacements tends to make me think "hash".

 
my %default_bind = ( age => 23, height => 75, birthday => undef );
my @key_order = qw( age height birthday );

sub {
    my $caller=shift;

    my @bind = @{ { %default_bind, @_ } }{ @key_order };

    $rf->execute(@bind) or
        $caller->complain("Error executing this and that.");

    $rf->fetchall_arrayref;
}
[download]

Or, assuming the order of arguments to the callback is well-defined, what about just doing the undef element replacement in-line? (Shown verbose for clarity):

sub {
    my $caller=shift;
    $rf->execute( map { defined $_ ? $_ : shift @_ } @bind ) or
        $caller->complain("Error executing this and that.");
    $rf->fetchall_arrayref;
}
[download]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

This is certainly an interesting approach. "Philosophically" of the same breed as mine, IMHO, but somewhat cleaner.

Of course I would rather prefer to be able to do something just as simple as

    $rf->execute(@_) or
        $caller->complain("Error executing this and that.");
[download]

where obviously I may not really be using all of the (unprocessed) @_, but more realistically a list prepared from @_.

my %default_bind = ( age => 23, height => 75, birthday => undef );
my @key_order = qw( age height birthday );
[download]

Nice concept! Except that having to explicitly specify (some) keys in two places is again inelegant and error-prone. I would rather adopt some automatized mechanism along the same lines. Thanks for the input, anyway! It gave me an idea about the direction in which to proceed.