I would recommend for now explicitly setting "mysql_auto_reconnect =>
0" in your connect_info options hashref and seeing if this clears up
your problem.
Yes, setting
mysql_auto_reconnect => 0
disables internal DBD handling of auto-reconnect and on_connect_do SQLs
works.
perhaps we should explicitly set mysql_auto_reconnect to off in
Storage::DBI? (since it has a "mysql_", I suspect we could set it
there and other drivers would ignore it - putting it in the proper
subclass would be a pita since we don't rebless into the subclass
until after connecting).
I think this is what typical user could expect. Now it is rather buggy
when you put some statements into "on_connect_do" but nothing happens
after reconnection and you think "%^&$! it doesn't work!"
There is probably not so much difference in performance between
DBD::mysql ping /reconnect and DBIx reconnect, using the second one give
us some portability across DBs.
--
[EMAIL PROTECTED] http://www.hurra-communications.com/
$ o m e t e a m . d e v e l o p e r
Hurra Communications, Krakow/Stuttgart/London/Paris/Madrid
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
