Hi!
The situation with mysql tests has improved lately, but I still have the
following tests breaking on my system. It would be nice if some of the
maintainers would address it as I'm sure it happens to others too.
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 before.
EXPLAIN - metadata [ext/mysqli/tests/mysqli_explain_metadata.phpt]
The reason is that plain SQL and prepared SQL return different data -
catalog field sometimes is "def", sometimes NULL in MYSQL_FIELD
structure returned by mysql_fetch_field_direct(). It may be mysql bug in
which case test should be SKIPed for versions that have this bug.
API vs. SQL LAST_INSERT_ID() [ext/mysqli/tests/mysqli_last_insert_id.phpt]
The reason is that this test relies on LAST_INSERT_ID() being reset on
SELECT. I have not observed such behavior neither via PHP not talking to
Mysql server directly from CLI interface, so I have no idea why this
test assumes such behavior.
mysqli_stmt_num_rows() [ext/mysqli/tests/mysqli_stmt_num_rows.phpt]
This test for some reason assumes that while mysqli_stmt_num_rows()
would return 0 when applied to unbuffered statement it would start
returning number of rows when the result processing is done. This is not
the case for my ststem - it always returns 0, and this seems to be
consistent with mysql documentation. This change was introduced by:
r308394 | andrey | 2011-02-16 08:36:33 -0800 (Wed, 16 Feb 2011) | 3 lines
fixed a problem in mysqlnd. 0 was always as num_rows returned for
unbuffered sets (text protocol and PS).
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).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
