http://www.perlmonks.org?node_id=1003474

theleftsock has asked for the wisdom of the Perl Monks concerning the following question:

Good Morning. I poked around, and found some .cgi discussions about this, but did not find an exact answer to my question. I thought an eval{$string} would do it, but lets get to it, shall we?

I have a file, we'll call sql_string.sql that has a sql string in it, written to have some variable names in it. I want to read in that string, then send it to a sub along with HASHREF that contains the necessary variables. Then I want to swap out those var names for the var values. Maybe I need to explicitly deference the HASHREF? Any help would be great. BTW, I am not sure if there is better pragma for this. I am going to be doing a lot of switching on some SQL for various uses. i don't want to inline the SQL, and I want to be able assign values to various pieces for multiple use, so additional style comments are always welcome.

Sort of like this
my ($sql_var_hr); $$sql_var_hr{col_name} = 'column_name'; my $sql = get_sql($sql_han, $sql_var_hr); sub get_sql { my ($file_han, $vars) = @_; #vars is a hashref containing any swit +ch variables for the select my ($iline, $sql); print "vars: $$vars{col_name}\n"; while ($iline = <DATA>) { if ($iline =~ /^#/) { next; } else { $sql = $sql.$iline; } } print "pre_eval: $sql\n"; eval{$sql}; print "post_eval: $sql\n"; return $sql; } #the following are just attempts __DATA__ select $vars{col_name} from schema.table select $$vars{col_name} from schema.table select ${$var{col_name}} from schema.table
thanks in advance -theleftsock

Replies are listed 'Best First'.
Re: Evaling Strings in Subs for Hashref Variable Names to Values
by choroba (Cardinal) on Nov 12, 2012 at 16:21 UTC
    If you use next, there is no need to use else: the code after next can only be reached if the condition was not true.

    You do not want to use eval BLOCK to catch exceptions. You want to use eval STRING to evaluate a constructed code. You should include the assignment in the code, though:

    #!/usr/bin/perl use warnings; use strict; my $sql_var_hr; $sql_var_hr->{col_name} = 'column_name'; my $sql = get_sql($sql_var_hr); sub get_sql { my ($vars) = @_; my $sql; while (my $iline = <DATA>) { next if $iline =~ /^#/; $sql .= $iline; } print "pre_eval: $sql\n"; eval '$sql = "' . $sql . '"' or warn $@; print "post_eval: $sql\n"; return $sql; } __DATA__ select $vars->{col_name} from schema.table select $$vars{col_name} from schema.table
    Using "templates" might solve lots of problems this naïve approach might cause.
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

      Thanks for the response. I didn't think of evaling the assignment, that's what I missed. I had tried the string eval previously, but not the assignment. I did have strict and warnings in my original code, but dropped it to post a simple example.

      A templating system is a good idea, maybe break the SQL down into segments? Yea, it would be pretty easy to make mistakes, and hard to figure out what the var names are supposed to be. Hopefully in the beta implement of this I can solve some of those issues. Any recommendations on a templating system or process that is already established? I guess I could use some kind of markup....

      either way, thanks for the response! It's really helpful.

      -theleftsock
        I think SQL::Template might help you here. The SQL code is decoupled from your Perl-script and resides in an XML-file. The variable data is provided through a hash-reference.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        My blog: Imperial Deltronics