Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61115
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <4FF853C6.4030503@lerdorf.com>
References: <4FF853C6.4030503@lerdorf.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 09 Jul 2012 12:17:02 +0200
Message-ID: <1341829022.3766.19.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] MYSQL_OPT_RECONNECT
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Sat, 2012-07-07 at 08:20 -0700, Rasmus Lerdorf wrote:
> So, because of these bugs when MySQL turned off auto-reconnects in 5.0.3
> everyone has been running with them off despite pdo_mysql's intent to
> turn them back on. Fixing these bugs now to make the code do what it was
> intended to do would be a BC break. My suggestion is to just expose
> MYSQL_OPT_RECONNECT as a normal user-settable option (which wouldn't be
> available under mysqlnd) and leaving it off by default.
> 
> Looking through the bug db this was actually partially reported a while
> ago in bug 58863. Johannes/Stas is exposing MYSQL_OPT_RECONNECT ok for
> 5.3/5.4? I suppose it is a grey area between a feature change and a bug
> fix in this case.

I guess exposing it is ok, while I would advertise it. Doing the
automatic reconnect will mean strange things will happen as no state is
kept. So if you set any session variable (SET NAMES, timezones, SQL
mode, ...) they will be lost. This will become especially with the
recently proposed change to go to native prepared statements,thinking of
an example like this:

    $pdo = new PDO("mysql:...");
    $select = $pdo->prepare("SELECT * FROM t WHERE id = ?");
    /* do something ... connection break in between */
    $delete = $pdo->prepare("DELETE FROM t WHERE id = ?");
    $select->execute([1]);

This will in fact do a DELETE, not a SELECT as the statement handle
effectively is nothing but a per-connection counted unsigned long.

johannes