[CC'd to dbi-dev for general interest re DBIc_IMP_DATA] On Mon, Mar 17, 2003 at 10:46:29PM -0500, Rudy Lippan wrote: > > 2. Quick questions: > > 1. What exactly is DBIc_IMP_DATA(imp_dbh); used for? I see it in > DBD::mysql but not in DBD::Pg, DBD::Oracle or DBI::DBD.
It's an old and rarely used alternative way for a driver to attach information to a handle. The choices are: - Extending the imp_xxh structures (recommended for XS/C drivers) - Using the attribute cache hash (recommended in general) - 'Implementors data' - a single scalar, typically a hash ref I'd recommend moving away from DBIc_IMP_DATA as using it may complicate plans I have for changing handle creation. > 2. When you get a chance, could you send me your column info patch, so > that I can apply it before mucking too with the perl code? Attached. > Also looking at the auto reconenct, I think I can see why it defaults to > on, but for the life of me, I don't understand why this 'fix' was put into > the driver instead of telling people to fix their code. Grrr. I can. It's a very useful feature for some environments like mod_perl. If the database server has been bounced you don't want the next few requests (one for each child httpd) to fail. > Anyway, I > have a patch to add the mysql_auto_reconnect Attrubite. I left it > defaulting to on, however, because of the existing code that depnds on the > feature Fine. A way to get a count of how many auto reconnects have been made would be handy, but not important for me as I'll probably just disable it. > (I think one of the guys at the office is depending on this > feature without knowing it, but he was quite suprised when he found how > DBD::mysql fixed the 'morning bug'). :-) It certainly needs to be made very clear that any use of LOCK TABLE or GET_LOCK with DBD::mysql is currently unsafe as the locks can be lost without notice. Tim.
