Hi Meir.
So I was mistaken. mostly because usually when talking about retrieving
data, people mean retrieving it from the DB, not from perl itself.
Anyway, you eval line:
my $raw_string_1 = '{return "WHERE col = \'$sql_date\'"}';
eval $raw_string_1;
is equal to:
my $raw_string_1 = '"WHERE col = \'$sql_date\'"';
eval $raw_string_1;
as the string itself is a valid perl. you don't need to wrap it in more
syntax.
and is equal to simply:
"WHERE col = '$sql_date'";
as you are using eval to activate perl's string interpolation.
I can speculate that you are using this technique to imitate named
references, and passing them to a function that should 'fill the blanks'.
Let's call it 'delayed string interpolation'? :-)
well, it can work in a pinch, as long as you are sure that your data don't
have anything strange.
But still, if this thing will grew a bit, I'd recommend rethinking the
approach.
Shmuel.
On Fri, Aug 1, 2014 at 1:12 AM, Meir Guttman <[email protected]> wrote:
> Dear Shmuel,
>
>
>
> Yes, I am well aware that I am using Perl’s ‘eval’! And no, $dbh->do()
> cannot be used to *retrieve* data.
>
> But I had my share of the RTFM syndrom L. The very first line of the
> ‘eval’ page in perldoc is:
>
> *In the first form, the return value of EXPR is parsed and executed as if
> it were a little Perl program*.
>
> (my enhancement.) So I changed case #1 to be:
>
> *my $raw_string_1 = '{return "WHERE col = \'$sql_date\'"}';*
>
> That when eval’ed, yielded:
>
> *WHERE col = '2014-7-31'*
>
> As required.
>
>
>
> Sorry folks to bother you
>
> Meir
>
>
>
>
>
> *From:* Perl [mailto:[email protected]] *On Behalf Of *Shmuel
> Fomberg
> *Sent:* יום ה 31 יולי 2014 18:22
> *To:* Perl in Israel
> *Subject:* Re: [Israel.pm] Not understood behavior of 'eval'
>
>
>
> Hi Meir.
>
>
>
> I think that you are confusing perl's eval and DBI eval.
>
> Your code is using perl's eval,
>
> which is invalid for #1, (so you get undef and can check $@ for error
> string)
>
> and for #2, the evaluated string is $sql_date, so you get the date inside
> it.
>
>
>
> if you want to have SQL command to the DB, check the DBI module:
>
> https://metacpan.org/pod/DBI
>
> I think you are looking for the 'do' command.
>
>
>
> Shmuel.
>
>
>
> On Fri, Aug 1, 2014 at 12:15 AM, Meir Guttman <[email protected]> wrote:
>
> Please Perlers,
>
> The following script:
>
> <code>
> use strict;
> use warnings;
>
> my $sql_date = '2014-7-31';
>
> my $raw_string_1 = 'WHERE col = $sql_date';
> my $raw_string_2 = '$sql_date';
>
> my $evaled_1 = eval $raw_string_1; # yields 'undef'
> my $evaled_2 = eval $raw_string_2; # yields '2014-7-31'
>
> print "First: $evaled_1\nSecond: $evaled_2\n";
> </code>
>
> Yields 'undef' (and a concatenation warning) for $evaled_1 and '2014-7-31'
> for $evaled_2. Why???
>
> Notes:
> 1) I need the first form to work.
> 2) I am well aware of the DBI/DBD 'prepare()' with place holders. Mine is
> not the case for it, since 'col' is a run-time column name and so it cannot
> be assigned a place holder.
> 3) Neither can the date be assigned to a place holder. It is not always a
> date. The "WHERE" clause is an arbitrary complex compilation read from an
> INI file and various parts in it must be substituted by Perl variables
> values, also only determined at run-time.
>
> Thanks!
> Meir
>
> _______________________________________________
> Perl mailing list
> [email protected]
> http://mail.perl.org.il/mailman/listinfo/perl
>
>
>
> _______________________________________________
> Perl mailing list
> [email protected]
> http://mail.perl.org.il/mailman/listinfo/perl
>
_______________________________________________
Perl mailing list
[email protected]
http://mail.perl.org.il/mailman/listinfo/perl
