Paul,
DBI doesn't read the config file, DBD::mysql does.
Erm, yep, I meant that, too :-)
It's not expensive at all. Why do you think it's expensive?
As the file must be read and parsed at each ->connect(...) invocation.
It would be nicer if DBD could read the config file during the "use phase" (for example in BEGIN { ... } ). But I guess I am getting a little to perl-ish now :-)
DBD reads the config file (once) when it connects to the server. How would reading it in the "use phase" be any more efficient?
Hmm, I mean in a typical mod_perl application you connect to the server, issue a few queries, then disconnect. So if I am not mistaken, DBD reads and parses the config file at each connect call. (I am not very happy with connection pooling in mod_perl, like, say, in Apache::DBI... handlers are not shared, so there is no point... and you get a gazillion of live, but passive connections to the MySQL server, ending up MySQL eating up your memory even if your memory sharing is working nicely.)
If it were in the "use phase", parsing the file could happen once (when DBD is first loaded). The values in the config file could be parsed, be put in a hashref, and made class variables instead of instance variables.
It would be different if I could ...->new() a DBD instance, passing my.cnf to it (or even the full DSN string) - bascically using a DBD isntance as a singleton - and then ask that object for DBH-s. But that is not how DBI/DBD was meant to work.
So this is what I mean... please do correct me if I am wrong.
- Csongor ps: We are moving away from MySQL at great pace, though :-)
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
