Re: [PHP-DEV] mysqli tests breaking
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. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
On 09/05/2011 03:19 PM, Ulf Wendel wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
Libmysql only test, skipped if using mysqlnd. No mysqlnd-libmysql BC break here. Am 02.09.2011 19:19, schrieb Stas Malyshev: 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. Can't repeat. A wild guess: your systems network configuration has changed or whatever the external dependency may be, I do not know... PASS w network enabled on box: libmysql 5.1.37 libmysql 5.5.15 libmysql 5.6.2-m5 PASS w network disabled on box: libmysql 5.6.2-m5 You may be the right person to investigate as you claim to have observed a recent breakage. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
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 Mysqlnd will print: insert id for INSERT is: 1 insert id for SELECT is: 0 At the end of the day, we are discussing C library differences again, thus we can consult the C API reference: Returns the value generated for an AUTO_INCREMENT column by the previous INSERT or UPDATE statement. Use this function after you have performed an INSERT statement into a table that contains an AUTO_INCREMENT field, or have used INSERT or UPDATE to set a column value with LAST_INSERT_ID(expr)., http://dev.mysql.com/doc/refman/5.6/en/mysql-insert-id.html The test is using the function not after an INSERT but after a SELECT. The documentation continues: The return value of mysql_insert_id() is always zero unless explicitly updated under one of the following conditions: - [...] INSERT - [...] INSERT multi-row ... MySQL version dependent - [...} INSERT...SELECT and [...] - [...] INSERT...SELECT and [...] Followed by: 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. I read: - The return value of mysql_insert_id() is always zero unless explicitly updated under one of the following conditions - If you need to save the value for later, be sure to call mysql_insert_id() immediately after the statement that generates the value. If people like, we can call this mysqlnd interpretation a bug. In any case, I find no reference in the documentation that the value must NOT to be reset upon SELECT. Searching bugs.php.net gives one related case: https://bugs.php.net/bug.php?id=54190 Unfortunately, Andrey did not write down the MySQL bug he refers to. However, back in March he wrote something that makes be believe he interprets the manual similar to how I do: mysqli calls internally SHOW WARNINGS to fetch the warnings from the server. The SHOW statement should reset insert_id in libmysql, but it does not. To sum up: - debatable issue - edge case going beyond primary use of function - edge case not explicitly covered by the documentation - five lines(?) to change, if need be - quick check: no bug report on bugs.php.net against mysqlnd Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
Hi, On 09/05/2011 04:53 PM, Ulf Wendel wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
On 09/05/2011 08:07 AM, Andrey Hristov wrote: and here we see a bug. The value in libmysql is not reset, as the Documentation states. Clear bug. For cases where a test exposes a libmysql bug, especially if it is something that acts differently across different versions of libmysql, the test should remain a FAIL, but it should point to the mysql.com bug # so end users realize that they have a version of libmysql with that specific bug. In cases where there is no agreement whether something is a bug or just undefined behaviour it would be really nice if the library authors could work this out and agree on a common behaviour and failing that PHP should try to mask the internal Oracle/MySQL squabbles and present consistent behaviour to the user. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
Am 05.09.2011 18:49, schrieb Rasmus Lerdorf: In cases where there is no agreement whether something is a bug or just undefined behaviour it would be really nice if the library authors could work this out and agree on a common behaviour and failing that PHP should try to mask the internal Oracle/MySQL squabbles and present consistent behaviour to the user. Yes... :( . Ever heard a german saying innerer Schweinehund überwinden? That means convincing yourself to take the battle, to go the stony road, to motivate yourself. It pays out on the long run. In other words: our fault. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
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? On Fri, Sep 2, 2011 at 2:03 PM, Ulf Wendel ulf.wen...@phpdoc.de wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
Hi! On 9/2/11 11:03 AM, Ulf Wendel wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli tests breaking
Hi: While I mentioned the following in the 5.4 beta tests thread, I'll semi-re-post this here so it doesn't get lost in a thread not specifically about mysql tests. libmysql: http://www.analysisandsolutions.com/php/mysqli.test.failures.libmysql.tbz mysqlnd: http://www.analysisandsolutions.com/php/mysqli.test.failures.tbz mysqld Ver 5.1.41-3ubuntu12.10 for debian-linux-gnu on x86_64 ((Ubuntu)) Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] mysqli tests breaking
Am 02.09.2011 20:27, schrieb Stas Malyshev: On 9/2/11 11:03 AM, Ulf Wendel wrote: 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 Stas, I'm not arguing about test portability or the like. All I'm after is the counterpart to the checkbox entry Try a snapshot (PHP x.y) (Feedback), as found at bugs.php.net :-). 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. 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. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] mysqli tests breaking
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. 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. Otherwise for any user that doesn't run exactly the same library version as test developer ran, the test suite doesn't work - he doesn't have the means to identify if something is wrong or not. -- 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
Re: [SPAM?]: Re: [SPAM?]: Re: [PHP-DEV] mysqli tests breaking
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
