On Mon, 6 Sep 2004, Tim Bunce wrote:
> > So do we say that mysql_auto_reconnect will be disabled when server-side
> > prepared statements are in use?
>
> Yes. That's what I'd recommend. Personally I'd disable it by default
> and make applications ask for it explicitly if they want it.
> It's just not safe enough to leave on.
Ok. Easy enough. Right now it is only defaulting to on when it sees
$ENV{GATEWAY_INTERFACE} || $ENV{MOD_PERL}, so I will not turn it on when
serverside-prepare is true.
> > DBD::mysql's ping function uses the mysql API function mysql_ping() which will,
> > in the event that the server closed the connection, automatically reconnect to
> > the server and returns TRUE.
>
> http://bugs.mysql.com/bug.php?id=2532
Ah, IC.
> I think $dbh->ping should return false if the connection-id (thread-id)
> changes.
>
> (Perhaps return "0", rather than "" or undef, in this case.)
>
That sounds good, so I'll do that. It is not 100%, but should work.
> > And then there is the case of backwards compatibility. How many applications
> > have never had the if(0 == ping()) code tested, because ping would try the
> > re-connect?
>
> Not enough to worry about. Correctness is more important here.
>
Agreed.
> Tim.
>
> p.s. Did the last two items in http://www.mail-archive.com/[EMAIL
> PROTECTED]/msg02136.html
> get done? (I've no time to look.)
>
In 2.9002
* Changed the default behaviour of mysql_found_rows, so now
'UPDATE table set field=?' will return the number of rows matched
and not the number of rows physically changed. You can get the old
behaviour back by adding "mysql_found_rows=0" to the dsn passed
to connect.
And as for the connect attributes having to be passed in using the dsn, I don't
think that this is the case. Right now, everything in the dsn is added to the
dbh's attribute hash before new_dbh is called and _login is reading off of
the dbh's attribute hash when deciding what to do.
Thank you,
Rudolf.
