Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55107
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain phpdoc.de from 212.227.17.9 cause and error)
Message-ID: <4E613F48.5050106@phpdoc.de>
Date: Fri, 02 Sep 2011 22:40:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
CC: PHP Internals <internals@lists.php.net>
References: <4E611027.6000103@sugarcrm.com> <4E611A8E.5080108@phpdoc.de> <4E612003.6020303@sugarcrm.com> <4E612A4C.7080707@phpdoc.de> <4E61379A.6000005@sugarcrm.com>
In-Reply-To: <4E61379A.6000005@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [SPAM?]:  Re: [SPAM?]:  Re: [PHP-DEV] mysqli tests breaking
From: ulf.wendel@phpdoc.de (Ulf Wendel)

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,
>> http://dev.mysql.com/downloads/mysql/5.1.html . You are testing again
>> 5.1.4x. Generally speaking, libmysql 5.1.4x won't see updates, just like
>> PHP 5.2 won't.
>
> While it is a good advice in general, I seriously doubt the semantics of
> mysql_num_rows() or last_insert_id() SQL statement changed between
> 5.1.4x and 5.1.5x. That would be serious and profound change totally
> inaproppriate for such version and my quick check of the changelogs
> suggests nothing of the sort. So I'm afraid there's little hope that the
> failures I am observing are caused by not using 5.1.5x.

Stas,

aren't we going a little too far here in our discussion? We agree on the 
basic points. I'm not saying that your issues shall be ignored nor am I 
saying tests shall not be made portable. (But I won't spend my weekend 
looking into them right now ;-); I have intentionally not replied to 
that part of your mail.)

Being someone who has been forced to write many mysqli tests in the past 
I lost trust in changelogs and the like. Take 
https://bugs.php.net/bug.php?id=55001 from today. Shortly after my bug 
comment, a C variant of it has been checked on four platforms against 
six libmysql versions to dig it down for a mysql.com bug report. My 
5.1.4x is not affected, someone else 5.1.4x is. I can't reproduce with 
 >5.1.5, others can. Fun.

>> Regarding test portability ... you probably can imagine how annoyed I
>> have been when orginally writing tests and hitting non portable stuff,
>> deperately trying to actually test for something.
>
> I agree it is annoying, but we have to sort it out nevertheless. If we
> have tests that work only on some specific versions and break on others,
> we need either to identify breakage point and have them specifically
> pointed out (such as: "This test won't work on versions before X.Y.Z
> because mysql_foo_bar() function returns wrong value in foobar
> structure") and if possible, skipped out with informative message.

Argument taken. However, I'm afraid, we'll always see such things happen 
if any PHP extension depends on any external entity - be it a library or 
a database server.

My thinking is that any such test issue should be handled as a 
day-to-day task. A task not only perfomed the week before a beta 
release. Any user should do the test run any time. You'd probably sign that.

Need I say more, did I get your arguments?

Ulf