Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <4E630027.9030502@sugarcrm.com>
Date: Sat, 03 Sep 2011 21:35:51 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <4E611027.6000103@sugarcrm.com>
In-Reply-To: <4E611027.6000103@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: mysqli tests breaking
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

I've tried with latest mysql library and as I suspected, most of the 
issues still stay.
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 
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).

2. last_insert_id semantics change. The test expects select queries to 
reset last insert it to 0, which does not happen with libmysql. Maybe it 
happens on later versions of mysql server, I do not know - but we can't 
have a test the is bound to specific server version, at least not 
without a check, and even better - separating it from portable tests. If 
it's specific to mysqlnd it's even worse - it means that some code that 
assumes libmysql behavior will be broken, and as last_insert_id() is a 
very frequently used function I think it's very dangerous.

Also, new issue added with recent libmysql - newer builds of libmysql do 
not declare DBUG_OFF at all in my_config.h. See for example 
http://bugs.mysql.com/bug.php?id=60872. So we should take the absence of 
DBUG_OFF as a sign that debug is enabled. I would recommend checking if 
DEBUG_ON is defined and enabling debug only then.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227