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]

-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.

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.

Both. It was running Windows (and that is badly set up by definition) and the filesystem in question was samba, which used a linux box that in turn got its data through NFS. I hate seeing such configurations without being allowed to fix it.

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

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.

That's fixed in newer versions of Everything:

nbmasta export <nodeball>