[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