On Tue Sep 11, 2007 at 02:40:03PM +0200, Emanuele Zeppieri wrote: > 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?
Looks perfectly valid to me, with the usual proviso's associated with parsing / interpolating strings. > 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. Yep. Fully up to speed now. -- Mark Lawrence _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]