[Dbix-class] RE: SQL Generation with SQL::DB
Emanuele Zeppieri
ema_zep at libero.it
Tue Sep 11 13:40:03 GMT 2007
Mark Lawrence wrote:
>> That's why I was talking about string concatenations to build the whole
>> expression *before* evaluating it: though I don't like it in such a
>> situation it's even preferable since it saves you from (pre-)parsing the
>> expression [...]
>
> Could you perhaps give an example of the type of complex expression you
> are thinking of? And the pseudo code of where/how you would do the
> concatenation? I'm afraid I'm just not seeing your point.
Mark, the complex expressions I was thinking of are the ones showed in
points 2 and 3 of my last response to you (please, have a look at that).
For example let's see the dynamical relational operators case (point 2,
i.e. relational (comparison) operators not known until runtime).
Supposing you get the usual hash at runtime:
my $form = {
name => '= Mark',
age => '<= 30' ,
height => '> 180' ,
weight => '< 80'
};
with SQL::DB (*and* string manipulations) the code would simply be:
my @predicates;
while ( my ($field, $expr) = each %{ $form } ) {
push @predicates, '($table->' . "$field $expr)"
}
# It's a string!
my $full_expr_str = join ' & ', @predicates;
And then you can simply do:
my $expr;
eval '$expr = ' . $full_expr_str;
print $sql_db_schema->query(
select => [ $table->person_id ],
from => [ $table ],
where => $expr
);
It works since 'eval $string' is executed in the lexical context of the
calling program (I even forgot that, which makes things even easier :-)
I realized that SQL::DB was not conceived for that, but why shouldn't
the above code work?
Well, that's one of the situations I meant where SQL::DB could be useful
(even more in the example in point 4), *provided* that you resort to
string concatenations.
Please, let me know if I've finally been able to be clear.
Cheers,
Emanuele.
More information about the DBIx-Class
mailing list