No mysqlnd-libmysql BC break here.
Metadata and libmysql - there's hardly a better example why mysqlnd
should be set as a default. With libmysql as a default, PHP 5.4 will
have a randomly crashing default configuration.
https://bugs.php.net/bug.php?id=55001
On 09/05/2011 03:19 PM, Ulf Wendel wrote:
No mysqlnd-libmysql BC break here.
Metadata and libmysql - there's hardly a better example why mysqlnd
should be set as a default. With libmysql as a default, PHP 5.4 will
have a randomly crashing default configuration.
Libmysql only test, skipped if using mysqlnd.
No mysqlnd-libmysql BC break here.
Am 02.09.2011 19:19, schrieb Stas Malyshev:
new mysqli() [ext/mysqli/tests/mysqli_connect_oo_warnings.phpt]
This one just times out trying to look up the invalid DNS name. This is
a recent breakage, didn't happen
This is the one and only mysqlnd-libmysql difference of some practical
relevance. I consider it at least questionable if libmysql is correct.
If it was to be decided that mysqlnd is wrong, it is probably like five
lines of code in mysqlnd to change, if need be.
Am 02.09.2011 19:19, schrieb
Hi,
On 09/05/2011 04:53 PM, Ulf Wendel wrote:
This is the one and only mysqlnd-libmysql difference of some practical
relevance. I consider it at least questionable if libmysql is correct.
If it was to be decided that mysqlnd is wrong, it is probably like five
lines of code in mysqlnd to
On 09/05/2011 08:07 AM, Andrey Hristov wrote:
and here we see a bug. The value in libmysql is not reset, as the
Documentation states. Clear bug.
For cases where a test exposes a libmysql bug, especially if it is
something that acts differently across different versions of libmysql,
the test
Am 05.09.2011 18:49, schrieb Rasmus Lerdorf:
In cases where there is no agreement whether something is a bug or just
undefined behaviour it would be really nice if the library authors could
work this out and agree on a common behaviour and failing that PHP
should try to mask the internal
Am 02.09.2011 19:19, schrieb Stas Malyshev:
My environment is Mac OS X, libmysql version 5.1.46 (yes, I know it's
old, but that's what is out there in production for many, so we have to
support it).
Stas,
please, always test against the latest and greatest. Otherwise you'll be
testing
always test against the latest and greatest. Otherwise you'll be
testing against libmysql versions that are not going to see any updates.
I would disagree with that statement. Tests should be run against all
expected versions of the library. So if 5.1.46 is supported, it
should pass the
Hi!
On 9/2/11 11:03 AM, Ulf Wendel wrote:
please, always test against the latest and greatest. Otherwise you'll be
testing against libmysql versions that are not going to see any updates.
5.1 is still a supported version of Mysql. It is run on many production
servers, so I think we must
Hi:
While I mentioned the following in the 5.4 beta tests thread, I'll
semi-re-post this here so it doesn't get lost in a thread not
specifically about mysql tests.
libmysql:
http://www.analysisandsolutions.com/php/mysqli.test.failures.libmysql.tbz
mysqlnd:
Am 02.09.2011 20:27, schrieb Stas Malyshev:
On 9/2/11 11:03 AM, Ulf Wendel wrote:
please, always test against the latest and greatest. Otherwise you'll be
testing against libmysql versions that are not going to see any updates.
5.1 is still a supported version of Mysql. It is run on many
Hi!
On 9/2/11 12:11 PM, Ulf Wendel wrote:
This is no more than a friendly request to check against latest and
greatest to avoid hitting bugs already fixed in libmysql. Latest GA is
5.1.58, if I'm not mistaken,
http://dev.mysql.com/downloads/mysql/5.1.html . You are testing again
5.1.4x.
Am 02.09.2011 22:07, schrieb Stas Malyshev:
Hi!
On 9/2/11 12:11 PM, Ulf Wendel wrote:
This is no more than a friendly request to check against latest and
greatest to avoid hitting bugs already fixed in libmysql. Latest GA is
5.1.58, if I'm not mistaken,
14 matches
Mail list logo
