On Thu, 11 Mar 2004, Brett Randall wrote:
> On 11 Mar 2004, Skylos the Doggie wrote:
> > My solution to this problem is to pass EVERYTHING. I don't rely on
> > any subroutine to know Any data that isn't passed to it *explicitly*.
> > Using global or even local or even package variables is baad here.
>
> So if I want to have a database that is constantly available, I have to
> pass the connection details to every subroutine that runs?
Not necessarily. If you use Apache::DBI you can just do a
connect->statement->disconnect with the same DSN and username in your
code, but it won't actually reconnect, and will recycle previously used
connections. Speeds things up compared to the alternative and provides
you with the connectivity that you require.
I might attack the problem you describe of db connectivity by making a
function that gets the current DSN from a reliable virtualhost unique
place (the current $Application or something directly) and uses that to
make the connection on demand (using Apache::DBI for acceleration) each
time it needs to do something with the DB.
...You don't have a DB abstraction layer in your program... you're using
the dbi handle directly, aren't you?
> I'm not complaining here, it just seems like there's got to be another
> way... Although I'm definitely running short on ideas. Like I said in a
> previous e-mail, I'd love to see an example mod_perl app (with packages)
> that runs multiple copies off multiple databases simultaneously. Know of
> any? TIA.
In a fully object oriented environment this isn't a problem. Your
application instance holds a database connection instance which is always
available within that application, unique for the iteration... So it never
ends up being that kind of issue.
> > I advise either instancing yourself your own object to hold your
> > variables which holds all your methods (subroutines)
>
> Any good examples? I haven't yet ventured into OOP with Perl...
Ah, well, then nothing I say in an oop sense is going to mean much to you,
I think...
Well, think of, you have a hash with all your 'global' variables in it
that you pass around to everything. instead of $dbi->do(...) you say
$config->{'dbi'}->do(..). Thats the simplest way to think of it. by
intializing and passing this hash on each iteration of page visit, you
will always have the correct 'global' data.
In OOP, that hash is implicit, and it can have subroutines.
$config->getdbi()->do(...) or better yet, $config->do(...) automatically
executes it for you.
> > or passing all these values to your subroutines, or defining your
> > subroutines at execution time to anonymous variables.
>
> I don't know if, at a glance, the latter will work. I've got 15,000
> lines of code and that seems like a fairly major change...
mmm, sorta. Like changing myfunction($var1,$var2,$var3) to
$myfunction->($var1,$var2,$var3). It would be alot of change.
15,000 lines of code without OOP? Ouch. Thats a deep hole.
I think you're going to find very quickly that this code will not run in a
mod_perl environment with more than one configuration very well. Global
variables *bad*. Do you depend on mod_perl specifically or is it cgi
accelerated by mod_perl? You may need to fall back to mod_cgi until you
can rearchitect your program.
Skylos
- [EMAIL PROTECTED]
- The best part about the internet is nobody knows you're a dog.
(Peter Stiener, The New Yorker, July 5, 1993)
- Dogs like... TRUCKS! (Nissan commercial, 1996)
- PGP key: http://dogpawz.com/skylos/mykey.asc
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
