Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55210
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain oracle.com from 148.87.113.117 cause and error)
Message-ID: <4E649696.8090602@oracle.com>
Date: Mon, 05 Sep 2011 11:29:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <4E611027.6000103@sugarcrm.com> <4E630027.9030502@sugarcrm.com>
In-Reply-To: <4E630027.9030502@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: mysqli tests breaking
From: ulf.wendel@oracle.com (Ulf Wendel)

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