To the larger point, putting code in the database is a common but terrible idea. You won't be able to edit with any of your normal tools, or track changes with CVS, or diff it, or grep it, etc. I know it sounds great before you've tried it, but it really ends up being a problem for most projects that do it.

If the code is in a database, you cannot use the eval BLOCK form, but you must use the eval EXPR form. From the Camel book (p. 705):

The first form traps run-time exceptions (errors) that would otherwise prove fatal, similar to the "try block" construct in C++ or Java. The second form compiles and executes little bits of code on the fly at run time, and also (conveniently) traps any exceptions just like the first form. But the second form runs much slower than the first form, since it must parse the string every time.

For the do function there is no such thing as a do EXPR form; only do BLOCK and do FILE (and the deprecated do SUBROUTINE), so using your data-based scripts with do seems not feasible.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Good point. I was in a hurry to point out the problems with storing code in a database and forgot that this code would be in a variable.

There's not much need for do() these days.

But

my $config = do "~/.proggyrc" or die "config error: " . ($@ || $!) . "
+\n";
[download]

will always hold a special place in my heart... :-)

-sauoq
"My two cents aren't worth a dime.";

*sniff*

I too am quite fond of do or die.

You won't be able to edit with any of your normal tools, or track changes with CVS, or diff it, or grep it, etc. I know it sounds great before you've tried it, but it really ends up being a problem for most projects that do it.

So provide a file based interface :)

I had to work with code in a database once. It was great for performance (the filesystem on that box performed lousily), and writing check in/out scripts was only an hour or so work.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

If you got better performance from an RDBMS than from a fileystem, something was set up wrong on that machine. Or it was running an OS with a lame filesystem.

The devil is in the details, eh perrin.. :-/

Makeshifts last the longest.

Exactly. Perlmonks would be in much better shape if the Everything codebase didn't have this problem. As it is, just getting the code to the site is a chore.

my $code = $dbh->selectrow_array($sql)
  or warn "no code - ", $dbh->errstr;

do { eval($code); $@ } or warn "broken code - $@";
[download]

_________
broquaint

update: as sauoq rightly points out below, my code was b0rken (I was under the impression eval returned the value of $@, how silly of me) it's now been fixed with a do block hack

eval($code) or warn "broken code - $@";

That's a big oops.

The problem is that eval() returns whatever the eval'd code does. That would fail if the last expression in the code resulted in any false value, even if the code was perfectly fine. The Right Way™ is to check whether $@ is true.

my $result = eval($code); 
warn "eval borked: $@" if $@;
[download]

-sauoq
"My two cents aren't worth a dime.";