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 tests. Otherwise how will you know if you've broken a
supported environment?

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 against libmysql versions that are not going to see any updates.

Ulf

Hi!

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 support it - it's no use to run tests on the
bleeding edge versions while production runs different ones. And
production DB servers are upgraded very rarely, especially since 5.1 is
still supported and good enough for many users.
Having tests that run only on one version is next to useless, since that
means I'd never know if the code actually works in production - which is
the point of having the tests! If some specific test tests some fix that
available only since specific version - the test must be marked as such
and be skipped or disable the missing function in version that is too old.
I'm not saying we should support all Mysql versions since the start of
the project - but I do not see how 5.1 can be excluded.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Am 04.09.2011 06:35, schrieb Stas Malyshev:

The ones I'm most worried about are:

1. mysqli_stmt_num_rows() is expected to return number of rows after all
   rows were fetched while returning 0 before that. libmysql definitely

Yes, here the test assumes a marginally different behavior. The test
needs an update. No, there is no BC break.

doesn't do that, in full accordance with mysql docs which state row
numbers can't be had for unbuffered queries.
If we do want this new non-portable semantics in mysqlnd, we should have
it in separate test, clearly marked as such, even though I'm not
convinced having such semantics is a good idea at all (would lead to
applications working with mysqlnd and not with libmysql - invitation for
trouble).

Your description of the difference is wrong. You conclusion "invitation
for trouble" must be a joke.

a) The difference

Pseudo-code:

/* identical behavior */
mysqli_stmt_prepare(stmt, "SELECT ...");
mysqli_stmt_execute(stmt)
do {
assert(0 == mysqli_stmt_num_rows(stmt));
} while (mysqli_stmt_fetch(stmt);

/* difference now */
printf("number of rows fetched: %d\n", mysqli_stmt_num_rows());

Output:

libmysql: 0 rows fetched
mysqlnd: <actual_number_of_rows> rows fetched

Difference: mysqlnd lifts a silly libmysql limitation.

b) Practical relevance

bugs.php.net - 0 related reports

https://bugs.php.net/search.php?search_for=mysqli_stmt_num_rowsboolean=0&limit=All&order_by=id&direction=DESC&cmd=display&status=All&bug_type=All&php_os=&phpver=&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0

code.google.com - nobody using the function ?!
http://code.google.com/intl/en-EN/query/#q=mysqli_stmt_num_rows

Code that relies on undefined behavior:

num_rows = 0;
while (mysql_stmt_fetch(stmt)) {
  num_rows++;
}

/* Bogus code - does not follow docs */
if (num_rows && 0 !== mysqli_stmt_num_rows(stmt)
   printf("Damn, API returns a meaninful value"");
else
   printf("Jippie, MySQL folks lifted a limitation");

Worst that could happen is that someone relies on stmt_num_rows() @
mysqlnd here. Relying on any specific behavior is bogus. We are talking
about C libmysql (libmysql vs. mysqlnd) differences here, thus we can
check C API reference: "[...] Otherwise, the row count is unavailable
unless you count the rows as you fetch them. ",
http://dev.mysql.com/doc/refman/5.6/en/mysql-stmt-num-rows.html .

There is no promise made in the documentation that num_rows is set to 0.
"Unavailable" means that it can be set to any value. The return value
can be <num_rows_last_stmt>, 0 (libmysql) or the actual number of rows
(mysqlnd). None of this would violate the documentation.

This leaves us with:

• BC breakage is impossible because behavior is undefined
• update test, issue gone

Ulf

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
http://bugs.mysql.com/bug.php?id=62350

(Note how the issue is there, then gone and then back again depending on
version...)

Am 02.09.2011 19:19, schrieb Stas Malyshev:

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.

And, yet again metadata...

PASS EXPLAIN - metadata [ext/mysqli/tests/mysqli_explain_metadata.phpt]

libmysql 5.1.49 @ MySQL 5.1.49
libmysql 5.5.15 @ MySQL 5.1.49
libmysql 5.6.2-m5 @ MySQL 5.1.49

mysqlnd @ MySQL 5.1.49
mysqlnd @ MySQL 5.1.37

FAIL

libmysql 5.1.37 @ MySQL 5.1.37

... always use the latest and greatest. Libmysql bug, exact version
range is not known to me. Feel free to change the test to be skipped
during SKIPIF, for example, like this:

require(connect.inc)
if (!IS_MYSQLND && libmysql_version > ... && libmysql_version < ...)
die(skip libmysql bug)

At the first look, I can't find a related bug report at bugs.php.net.
Looks like few people compare PS and non-PS metadata for EXPLAIN in
their application.

this is exactly what I mean. If there was a bug in a previous version
and you try to use it, what do you want to see? SKIP or FAIL? I vote
with 2 hands for FAIL, because so I can easily spot problems when
migrating to a new version of PHP on my platform. If the test is made to
PASS, it should not be skipped unless it is not possible to run it -
like if it tests mysqli functions which are not available in libmysql's
build. But otherwise let it go, and if it FAILs, this is outside of our
problem. WE should not try to hide problems of third party software.

Our tests don't test only PHP, they test the whole platform they run on
to convince the end user that he can rely on the results of PHP on this
configuration.

Ulf

Andrey

Hi,

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 Stas Malyshev:

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.

Personal observation and memory may not be the best reference here. What
the test does is:

DROP TABLE IF EXISTS test
CREATE TABLE test(id INT AUTO_INCREMENT PRIMARY KEY) Engine=MyISAM

INSERT INTO test(id) VALUES (1);
printf("insert id for INSERT is: %d\n", mysqli_insert_id(link));

SELECT 1 FROM DUAL
printf("insert id for SELECT is: %d\n", mysqli_insert_id(link));

Libmysql will print:

insert id for INSERT is: 1
insert id for SELECT is: 1

and here we see a bug. The value in libmysql is not reset, as the
Documentation states. Clear bug.

Mysqlnd will print:

insert id for INSERT is: 1
insert id for SELECT is: 0

mysqlnd does what is expected, as in many other cases :)

During mysqlnd's development we found numerous bugs in libmysql and
reported them.

mysqlnd provided support for multiple result sets from prepared
statements more than year earlier than libmysql even had code to handle
this, which is in MySQL 5.5 now.

"mysql_insert_id() returns 0 if the previous statement does not use an
AUTO_INCREMENT value. If you need to save the value for later, be sure
to call mysql_insert_id() immediately after the statement that generates
the value."

Very clearly said.

LAST_INSERT_ID() is another story, but it has nothing to do with the
client library.

Andrey