[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre Joye schrieb: Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. What will they bring (saying expertise is not something I can buy)? I don't understand what is so hard to understand that it is a minimum to get before we can even discuss the CLA introduction. Let alone the fact that they don't consider us as good enough as discussions partner. Should be known, just to clearify... From MySQL side primarily Jay (Pipes) has been involved. Who can you talk to on MySQL side? Well, the usual suspects: me, Jay (Pipes), Georg (Richter), Kaj (Arnö), Giuseppe (Maxia), ... - and all the others being active in the PHP world. Who would contribute code? No clue, really. Check who has the skills for it and you can speculate, if that makes any difference to you. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Lars Strojny schrieb: Hi Lukas, hi Johannes, Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith: - MySQLnd what's with PDO MySQLnd, will it be part of 5.3? The PDO_MYSQLND extension, as I call it, is a patched PDO_MYSQL extension. PDO_MYSQLND is on the TODO list [1]. I hardly ever blogged about PDO_MYSQLND as a patch, although it is more of a patch than a new extension. PDO_MYSQLND reads shorter than a lengthy rather technical explanation. However, at some point we forked PDO_MYSQL and started to patch it to optionally support mysqlnd. This was the easiest way to add mysqlnd support to the PDO MySQL driver (PDO_MYSQL). PDO_MYSQL was the last MySQL extension in row to be upgraded to support both mysqlnd and the MySQL Client library (AKA libmysql). ext/mysql and ext/mysqli can already be compiled against the MySQL Client library, like ever since (= 100% BC), or be compiled against mysqlnd. Early versions of the patch did have a very poor quality. By poor I mean poor - like 60% of the tests crashing. Things became better in April (MySQL UC, alpha release). But the April version was still not good enough to be checked into the PHP 5.3 CVS repository. It was clear that it would take several more months to get the job done with the resources assigned to it. From the mysqlnd development we know that only very few PHP users are interested in bloody steaks. So, why should bad boy MySQL break the php.net PHP 5.3 repository and mess up PDO_MYSQL for months instead of stabilizing the patch first? In particular if there is no pressing reason... Those who want alpha code can get it from us at any time. We did a tough development sprint in the last weeks to make the patch ready for the tentative PHP 5.3 release plan. Our internal release plan shows no coding between Beta and GA but fixing newly reported bugs. All coding was planned to be done by the release of a beta - we have reached some 80% of the beta goals. I expect Dmitry to bail out about PDO_MYSQLND quality and performance. Dmitry/Zend is doing some excellent QA behind the scenes. But I do not expect any user to complain about us delaying a PHP 5.3 release by checking in unstable and buggy code. The patch (PDO_MYSQLND) won't break PDO_MYSQL anymore if it goes into the PHP CVS. Johannes is working on a 3-stars change (***zval) to both PDO and PDO_MYSQLND which I would like to test first before the patch (PDO_MYSQLND) goes into the PHP 5.3 CVS. That's days, not weeks, just enough time to see people discuss the tentative PHP 5.3 release plan and the PDO_MYSQLND entry on it. Ulf [1] http://wiki.php.net/todo/php53 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Lukas Kahwe Smith schrieb: On 14.07.2008, at 11:29, Ulf Wendel wrote: Lars Strojny schrieb: Hi Lukas, hi Johannes, Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith: - MySQLnd what's with PDO MySQLnd, will it be part of 5.3? [snip] Johannes is working on a 3-stars change (***zval) to both PDO and PDO_MYSQLND which I would like to test first before the patch (PDO_MYSQLND) goes into the PHP 5.3 CVS. That's days, not weeks, just enough time to see people discuss the tentative PHP 5.3 release plan and the PDO_MYSQLND entry on it. The patch should be in CVS by July 24th. It will be ready. I even dared to take a few vacation days last week... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Jani Taskinen schrieb: Ulf Wendel wrote: We did a tough development sprint in the last weeks to make the patch ready for the tentative PHP 5.3 release plan. Our internal release plan shows no coding between Beta and GA but fixing newly reported bugs. What about the already reported (a.k.a. old) bugs? :) Have a look at the bug overview at http://blog.ulf-wendel.de/?p=190 . Many old PDO_MYSQL bugs have been fixed. I don't claim the list to be complete. If you are worried about any particular bug, let me know. A good number of reported bugs are PDO bugs not driver bugs. For example the LIMIT issue is reported frequently as a PDO_MYSQL bug although it is a side-effect of the PDO SQL parser [1]. Several new bugs have been found in PDO_MYSQL and PDO. We have not worked on the PDO bugs as we have focussed on our driver first. Ilia fixed some of the major ones. Other bug reports are about minor issues. The thingie Johannes is working on is teaching PDO not to copy zvals from the drivers but supporting drivers who want to manage zvals themself, such as mysqlnd does. This change will prevent that we run into another issue where mysqlnd and PDO logic clash and PDO rejects a number and returns NULL instead of the number - the only show stopper I know of. All other issues I see are rather minor ones. Cross platform testing has been performed on: AIX 5.3 ppc64 FC4 x86 FreeBSD 6 x86, x86_64 HP UX 11.23 ia64 MacOS X 10.4 ppc32, x86 RHEL 3 ia64, x86, x86_64 RHEL 4 ia64, x86, x86_64 SLES 9 ia64, x86, x86_64 Suse 10.3 x86, x86_64 Win32 Solaris 8 to 10 failed to compile SPL with (Sun) CC last wednesday. I haven't looked into it yet. Win64 is missing. Anyway, the first X-platform results are very good, given that I haven't tuned the tests for x-platform compatibility yet. Ulf [1] http://blog.ulf-wendel.de/?p=191 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Jani Taskinen schrieb: Well, connection issues using mysqlnd seems to be pretty commonly reported, like this: http://bugs.php.net/45468 Aaah, you're talking about mysqlnd @ ext/mysql[i] - different story altogether. There are 20 open reports currently: http://bugs.php.net/search.php?cmd=displaybug_type[]=MySQL+relatedbug_type[]=MySQLi+relatedstatus=Openorder_by=idphpver=5limit=50 It seems that Pierre's hypothesis that the community would take care and help out is wrong. Andrey and I work on a different projects since a few months. Its been only a development sprint that made me getting back to PHP. No doubt we need to fix them. Andrey ^. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Lukas Kahwe Smith schrieb: there are also a few in PECL: http://pecl.php.net/bugs/search.php?cmd=displaystatus=Openpackage_name[]=PDO_mysql Ok, that's PDO_MYSQL. We checked both pecl.php.net and php.net bug lists. Are there any plans to improve the PHP bug systems to allow: - prioritizing a bug - add progress reports This would help to, for example, mark http://pecl.php.net/bugs/bug.php?id=12401 as in progress or is that assigned. But assigned often means yes, I should, but next year Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Hi Lars! Lars Strojny schrieb: Is there a way to checkout the source. I would love to test PDO_MYSQLND. Not yet. Andrey will need a day or so. I've CC'd him. He can post instructions here. The internal mysqlnd repostory, which includes the code for PDO_MYSQLND, was among the first to be migrated to Bazaar. This was long before the migration of the MySQL trees was announced [1] and long before the infrastructure for public access was ready. Blame me for not pushing on public access to the bzr repro earlier... Ulf [1] http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Pierre Joye schrieb: Drop the launchpad and use php's cvs. We have actually two development branches (5.3 until the 24th and HEAD) and PECL. The latter let you experiment as much as you wish. Pierre, you are not in the position to tell us what repository we use for internal developments and experimental features. Or should I start flaming againt the developing of a new PHP parser at svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of developers in your world. The bad and the good. The good can use their own repositories. The bad may not. And MySQL is bad. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Pierre Joye schrieb: On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel [EMAIL PROTECTED] wrote: What's your point, what requests are you talking about? Please ask Johannes, I told them to him live last time we met. If there is doubts, I will happily repeat them. So, you have one question related to Windows builds - I did not know that. According to Johannes you both have chatted on IRC about it after you met. The chat did not help to clearify the question. Can you rephrase the question, what version of PHP are we talking about? I saw one person complaining about mysqlnd being compiled into PHP although no mysql extension was compiled into PHP: bug - open to anybody to fix. Ok, I will fix that as It does not make sense to enable mysqlnd when no mysql extensions are enabled (but that's the least of my worries). Cool. Its annoying to see anything in a binary which is not needed (here: mysqlnd). Like it makes no sense to have ext/pdo compiled into PHP if no driver is compiled into PHP. I hope we're not down to a point where we really need consult each other for such a minor change... PHP has a very vivid team of developers fixing many issues before they go down to the maintainers, see the constant work on bug reports. I relied on that to happen. Is that the issue you are talking about? How can that happen when you do many maybe unrelated changes in one commit? How can I (or other) granulary review a commit in this case (if something is broken)? I have no clue if Andrey has combined several fixes in one commit. At this point I have to rely on him choosing a proper granularity for a commit. Too large commits can always happen. You can work for a month in your local CVS copy and commit 100k at one - no difference. We are one week before a freeze and we just see than one of the most important change for this release is developed outside our tree, I seriously hope that you understand our worries (I'm not alone to worry). We may not have have the time to deal with the last minutes issues introduced by a last minute sync (== disable). So, this is the real issue behind this discussion, or is there more, such as the Windows question from above? mysqlnd has been committed into PHP 5.3 branch (and into HEAD) in October 2007. Since then several updates have been comitted into the CVS. This is yet another update. For whatever reason you seem to see a difference between this and previous updates. Do you want to hint that no extension maintainer should update their extensions any more due to the announced code freeze on July, 24th because you do not have enough time between code freeze and alpha 1? If so, the time between code freeze and alpha 1 seems too short. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Pierre Joye schrieb: On Tue, Jul 15, 2008 at 7:05 PM, Ulf Wendel [EMAIL PROTECTED] wrote: Pierre Joye schrieb: On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel [EMAIL PROTECTED] wrote: What's your point, what requests are you talking about? Please ask Johannes, I told them to him live last time we met. If there is doubts, I will happily repeat them. So, you have one question related to Windows builds - I did not know that. According to Johannes you both have chatted on IRC about it after you met. The chat did not help to clearify the question. Can you rephrase the question, what version of PHP are we talking about? Can you reply to this? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Marcus Boerger schrieb: Tuesday, July 15, 2008, 4:32:10 PM, you wrote: Pierre Joye schrieb: Drop the launchpad and use php's cvs. We have actually two development branches (5.3 until the 24th and HEAD) and PECL. The latter let you experiment as much as you wish. Pierre, you are not in the position to tell us what repository we use for internal developments and experimental features. Or should I start flaming againt the developing of a new PHP parser at svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of developers in your world. The bad and the good. The good can use their own repositories. The bad may not. And MySQL is bad. You really proove here that a) our communication needs to get better and that blogs don't help as they are ignored ffrom most developers. And b) we reallt need to most to a better repository like SVN or HG. Other than that, nobody tells you what you do or use. We just would like to know. And in regards to re2c I can only repeat what Scott said. It was a one time experiment that was announced on the list to be followed along and comitted as a whole as soon as agreed on (not when finished to be precise). You get me wrong. I know very well that blogs and development lists do have different target audiences. And I know that PHP development and development discussions do not only take place on the mailing lists but also on open and closed IRC channels as well as during public and private meeeting. I tried to follow the circus several years in the past but I settled down as you know... If I blog about PDO bugs and post bug summaries, its for the users and readers of the Planets. Being asked about the status, I would not hesitate to post a blog URL again over here. I am not asking for improvements around CVS. I am not convinced that a system should be used which can link to other repositories. The re2c decision is perfectly valid. Such as its valid to keep local copies of the CVS and work on them - even if those local copies reside in yet another repository. Marcus, we don't need to discuss the pros and cons of this in length. Your message has been clear in your first reply to the commit. Same goes for Jani (or a little later Lukas). Day-to-day mysqlnd changes shall go into the CVS as soon as possible. Andrey already explained that he applied hot fixes to the CVS (only) recently. Larger changes, new ideas might not go into HEAD in the first place but mature on the disk of the developer before they get published. This is not about commercial vs. non-commercial. There are no plans for commerical features in mysqlnd which would require a secret repository. The code will always go public. A little sooner without an internal review or a little later after a mandatory internal review. To me this seems similar to two PHP fellows discussing a patch in private for some time. I was recently asked about Unicode support in Postgres and MySQL. The question implied that Postgres is said to be ahead of MySQL. After all the years, I'm a bit tired of such questions. I replied with an enumeration of the advantages of the two systems. Hey, this reminds me a bit of this discussion. To reply to your last point: I don't think the communication between us is not working. For example, Jani's short reminder on open ext/mysqli bugs (try the search again...) is almost sure to cause a re-allocation of Andrey for a few days. And believe me, even those few days hurt and cause discussions. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Derick Rethans schrieb: On Tue, 15 Jul 2008, Andrey Hristov wrote: I am pretty lazy, thus I use my Thunderbird as a RSS reader. I get planetmysql as a feed and if I am not interested in an article, I skip it. It doesn't require even to go anymore to planetmysql . But even more, Ulf is also on planetphp, so you will get the message, if there is something. Sorry, but those things should go to the mailinglist. Have it also on a blog is fine, but I doubt every php developer follows planet PHP as there's so much nonsense on it. I'm sure there's no need to discuss the differences between an article/blogging and development discussions on other channels. Is there any particular blog posting which has been must go dev-list in your eyes? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Pierre Joye schrieb: On Wed, Jul 16, 2008 at 6:13 PM, Ulf Wendel [EMAIL PROTECTED] wrote: Derick Rethans schrieb: On Tue, 15 Jul 2008, Andrey Hristov wrote: I am pretty lazy, thus I use my Thunderbird as a RSS reader. I get planetmysql as a feed and if I am not interested in an article, I skip it. It doesn't require even to go anymore to planetmysql . But even more, Ulf is also on planetphp, so you will get the message, if there is something. Sorry, but those things should go to the mailinglist. Have it also on a blog is fine, but I doubt every php developer follows planet PHP as there's so much nonsense on it. I'm sure there's no need to discuss the differences between an article/blogging and development discussions on other channels. Is there any particular blog posting which has been must go dev-list in your eyes? Can you not simply post everything relevant to PDO and php internals to the internals list? Like bug reports, improvements, RFC, etc. (is it not obvious?) No, it is not obvious. Bug reports filed by myself since February: [ 1] http://bugs.php.net/bug.php?id=45432 [ 2] http://bugs.php.net/bug.php?id=44409 [ 3] http://bugs.php.net/bug.php?id=44173 [ 4] http://bugs.php.net/bug.php?id=44154 [ 5] http://bugs.php.net/bug.php?id=44151 [ 6] http://bugs.php.net/bug.php?id=44337 [ 7] http://bugs.php.net/bug.php?id=44362 [ 8] http://bugs.php.net/bug.php?id=44159 [ 9] http://bugs.php.net/bug.php?id=44202 [10] http://bugs.php.net/bug.php?id=44200 [11] http://bugs.php.net/bug.php?id=44166 [12] http://bugs.php.net/bug.php?id=44189 [13] http://bugs.php.net/bug.php?id=44169 [14] http://bugs.php.net/bug.php?id=44158 [15] http://bugs.php.net/bug.php?id=44155 [16] http://bugs.php.net/bug.php?id=44327 Bug reports I have gone through and check if they are related to PDO_MYSQL - which they are not in my eyes. I have commented in the bug system to all of them but one: [17] http://bugs.php.net/bug.php?id=40740 [18] http://bugs.php.net/bug.php?id=44707 [19] http://bugs.php.net/bug.php?id=42322 [20] http://bugs.php.net/bug.php?id=43443 [21] http://bugs.php.net/bug.php?id=41125 Bug reports which are related to PDO_MYSQL and which I have commented on in the bug system: [22] http://bugs.php.net/bug.php?id=41997 [23] http://bugs.php.net/bug.php?id=42499 [24] http://pecl.php.net/bugs/bug.php?id=12794 [25] http://pecl.php.net/bugs/bug.php?id=12401 Improvements: I have offered 44 new general PDO tests on the php-qa mailing list in late April, http://marc.info/?l=php-qam=120949456225995w=2 . 44 new means roughly +100%. The PDO bug list has a shocking length of 99 entries: http://bugs.php.net/search.php?search_for=boolean=1limit=Allorder_by=direction=DESCcmd=displaystatus=Openbug_type[]=PDO+relatedphp_os=phpver=assign=author_email=bug_age=0 . What improvements or RFC's did I blog about instead of sending them to the PHP development list. Its just not obvious to me. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Pierre Joye schrieb: hi, On Wed, Jul 16, 2008 at 7:27 PM, Ulf Wendel [EMAIL PROTECTED] wrote: What improvements or RFC's did I blog about instead of sending them to the PHP development list. Its just not obvious to me. No idea, and that's the problem. I do read the bug reports, not your blog. Pierre, although you do not read my blog you seem to be sure about its contents: bug reports, improvements and RFCs. Stuff thatshould have gone to the development lists. I proved that I did file PDO bugs and work on PDO bugs since February. I offered new tests for PDO on the PHP QA list in April. I commented to the PDO v1 Improvements RFC [1], written by and blogged about by Lukas [2], on the PHP PDO mailing list [3] in May. What is wrong with a blog that you do not read? Ulf [1] http://wiki.php.net/rfc/pdov1 [2] http://pooteeweet.org/blog/1048 [3] http://news.php.net/php.pdo/166 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Lester Caine schrieb: Ulf Wendel wrote: If mysqlnd turns out to be stable enough during the PHP 5.3 test phase, PHP 5.3+ may use mysqlnd as a default. There is no need to download an extra library when using 5.3. Lukas, this is not affecting PHP 5.3 as long as mysqlnd is stable/fast/... enough to be used as a default. BUT - does mysqlnd produce data in phpinfo() ? So when loaded by default you confuse end users when looking for problems on systems that do not use MySQL. We discussed that earlier in the thread: there's no need to load mysqlnd if there's no mysql extension loaded and using it - BUG, though not a high priority one. Just like there is no need to load ext/pdo when no pdo driver gets loaded. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / run-tests.php
Moin Marcus! Marcus Boerger schrieb: to be honest this is the wrong way. The correct way of fixing this is to have PHP 6 name it correct: string and binary. And to have b for binary prefix rather then u for unicode. Or did PHP 6 change in the meanwhile and we support uNonsense besides bBinary? I'm not sure if a change to PHP would help solving the original question on portable tests which I raised on the QA list. I asked for a way to write portable tests. That is a test which can be run on both PHP 5 and PHP 6 -- one file for both PHP 5 and PHP 6 (like in early PHP 6 days with UEXPECTF), not two versions that need to be kept in sync (like nowadays). Currently we have: PHP 5 var_dump(PHP . chr(0) . rocks!) -- string(9) PHProcks var_dump((binary)PHP . chr(0) . rocks!) -- string(9) PHProcks PHP 6 var_dump(PHP . chr(0) . rocks!) -- unicode(9) PHProcks var_dump((binary)PHP . chr(0) . rocks!) -- unicode(9) PHProcks The patch to run-tests.php allows you to use in your EXPECTF or EXPECTREGEXP section: %unicode|string%(9) PHProcks With PHP 5, run-tests.php will search for string(9) PHProcks and with PHP 6 it will search for unicode(9) PHProcks: one EXPECTF section, one test file for both PHP 5 and PHP 6. If I get you right, you suggest that it should read as follows in PHP 6: var_dump(PHP . chr(0) . rocks!) -- string(9) PHProcks var_dump((binary)PHP . chr(0) . rocks!) -- binary(9) PHProcks This may be correct and desired. However, if you change it, I'm back to my question: is there a way to write a portable test? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / run-tests.php
Marcus Boerger schrieb: to be honest this is the wrong way. The correct way of fixing this is to have PHP 6 name it correct: string and binary. And to have b for binary Aside from the question of how to write a portable test, here is an example speaking for your argument of making a distinction between binary (strings) and strings (= always unicode) in the var_dump()/print_r()/etc. output of PHP 6. In early PHP 6 days var_dump((binary)PHP) has printed string, like PHP 5 does. And in earlier versions of PHP 6 var_dump(PHP) has printed unicode. There was a distinction between the two types of strings in PHP 6. That was nice, because it was simple to test if SELECT varbinary_column really returned a binary (string) or a (unicode) string. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_set_charset
Stanislav Malyshev schrieb: I notice that mysql_set_charset function is not part of 5.3 tree and it's test is marked as usage not recommended. Could you explain what is the reason for that? It's quite unusual to drop functions in later versions, and if mysql_set_charset() has some problem we should note that in the manual. Hi Stas, good find! I think it has happened accidently in 5_3 at Revision 1.213.2.6.2.16.2.2 when patching ext/mysql for mysqlnd some 10 months ago [1] . Its in 5_2 and its in HEAD. Andrey is working on re-introducing it to ext/mysql in the 5_3 branch. I don't recall why I added usage not recommended to the test. Let me check with Georg. He had some concerns on the function as far as I remember. Ulf [1] http://cvs.php.net/viewvc.cgi/php-src/ext/mysql/php_mysql.c?r1=1.213.2.6.2.16.2.1r2=1.213.2.6.2.16.2.2 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_set_charset
Ulf Wendel schrieb: and its in HEAD. Andrey is working on re-introducing it to ext/mysql in the 5_3 branch. There it is http://news.php.net/php.cvs/52063 Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_set_charset
Ulf Wendel schrieb: I don't recall why I added usage not recommended to the test. Let me check with Georg. He had some concerns on the function as far as I remember. I checked with Georg. My memories regarding Georg's position are totally wrong. He once introduced mysql_set_charset to the MySQL Client Library (AKA libmysql - marketing gets confused when I use libmysql, sorry). He explained to me that using SET NAMES is what is not recommended when using libmysql because: - there is no verification if the client knows the charset - the internal mysql-charset field will not be set properly I don't know how that usage not recommended comment has crept in the test. Probably my fault... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/mysqli @ mysqlnd: unofficial MySQL Server patch for types results / native types
Hi!
Based on some discussions with Facebook, Tuenti and Andrey we have
developed an unofficial MySQL Server patch. Furthermore we have added
a new function to ext/mysqli which only purpose is to access
functionality available only with a patched MySQL Server. Therefore we
have not committed this new function into the PHP CVS but only made
available on Launchpad [1]. The license is - as usual - PHP license. If
you want it in the PHP CVS, we can add it, but I am -1.
Let me give details: the background.
When fetching data from MySQL in PHP using any of mysql_query(),
mysqli_query() or mysqli_real_query(), you will get a result set that
consists of PHP string and PHP NULL variables. The reason for that is
that the protocol used between the client and server is text based. The
client (PHP) receives all results as strings. Regardless of the SQL type
used in MySQL, you will get a string. For example, INTEGER 1234
becomes string 1234
If you use Prepared Statements you will get typed results, sort of
native types as I like to call them. As far as possible you will get
typed results. For example, INTEGER 1234 from MySQL becomes integer 1234
in PHP. That is because MySQL is using a different protocol using
different data encoding: the binary protocol for sending data to the client.
There is a number of reasons why you want native types / typed results
in PHP. Comparing $some_int_as_string with 1234 is slower than comparing
$some_int_as_int with 1234 - no type conversions need to be done before
the comparison can be done. $some_int_as_string requires a few bytes
more than $some_int_as_int to be stored. And, of course,
$some_int_as_string === 1234 will evaluate to false. Last but not least
its a convenience feature.
On the server side the binary protocol can save a few cast operations
and on the wire the footprint can (does not have to be!) a little smaller.
How big is the difference for the average user? Rather minimal. But
under high load you appreciate each and every possible optimization.
Putting it into a larger scale, memory savings inside PHP can translate
into memory savings in caches such as APC and memcached.
How can you get types results?
You can get typed results with any of [mysql_query(),] mysqli_query() or
mysqli_real_query() by either:
a) patching the server
b) casting upon fetch inside PHP using meta data information
NOTE: b) = PHP 5.3+, ext/mysqli using mysqlnd
Andrey has hacked a patch for the server. The server patch is by no
means official - its a suggestion for those who want to experiement. I
don't know if the patch will ever go into MySQL. The patch will make the
server use the binary protocol for mysqli_query() after setting an
option. To be able to set this new option, available only with a patched
server, we have exported the C function mysql_set_server_option() to
ext/mysqli as mysqli_set_server_option(). This is not in the PHP CVS
currently because:
1) you need it for nothing but accessing a patched server
2) you can mess around with MYSQL_OPTION_MULTI_STATEMENTS_ON which
has been keept away from the mysqli API so far and encapsulated in an
extra function mysqli_multi_query().
3) we try to block you from messing around with
MYSQL_OPTION_MULTI_STATEMENTS_ON
Therefore: no functionality hidden that is available in the regular
MySQL Server. The function would be API bloat in regular PHPs. So, we
keep like 10 lines of code only in our bazaar repository at Launchpad [1].
b) is in the PHP CVS. Its available with ext/mysqli when compiled
against mysqlnd. Here's a simple usage example:
$link = mysqli_connect(localhost, root, root);
mysqli_query($link, USE test);
mysqli_query($link, DROP TABLE IF EXISTS test);
mysqli_query($link, CREATE TABLE test(col1 INT, col2 FLOAT));
mysqli_query($link, INSERT INTO test(col1, col2) VALUES(1, 12345.67));
$res = mysqli_query($link, SELECT col1, col2, col2 * 2 AS _col3 FROM
test);
var_dump(mysqli_fetch_assoc($res));
mysqli_free_result($res);
/* mysqlnd only */
mysqli_options($link, MYSQLI_OPT_INT_AND_FLOAT_NATIVE, true);
$res = mysqli_query($link, SELECT col1, col2, col2 * 2 AS _col3 FROM
test);
var_dump(mysqli_fetch_assoc($res));
mysqli_free_result($res);
mysqli_close($link);
---
array(3) {
[col1]=
string(1) 1
[col2]=
string(7) 12345.7
[_col3]=
string(14) 24691.33984375
}
array(3) {
[col1]=
int(1)
[col2]=
float(12345.7)
[_col3]=
float(24691.33984375)
}
I'll be in meetings for the rest of the day, please be patient if I
don't reply to questions immediately. More details and thoughts on the
idea can be found at [2].
Ulf
[1] https://code.launchpad.net/~andrey-mysql/php-mysqlnd/binary_protocol
[2] http://blog.ulf-wendel.de/?p=198
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] License for Windows binaries
William A. Rowe, Jr. schrieb: Well, the binaries probably include c runtimes under liberal MS license. They might be kind and give you mysql and a host of other GPL features under a very restrictive license. With any PHP before 5.3, you'll have to compile any of the MySQL extensions (ext/mysqli, PDO MySQL, ext/mysql) against the MySQL Client Library (libmysql). libmysql is GPL + FLOSS Licence exception [1]. As of PHP 5.3 you can optionally compile all the MySQL extensions against the MySQL native driver for PHP (mysqlnd) instead of compiling against libmysqlnd. mysqlnd is part of the PHP source tree and as such licensed under the terms of the PHP license. PHP's license is, as Cristian says, very liberal and you have nothing to worry about until you link to something ;-) Go PHP 5.3, go mysqlnd ;-) Ulf [1] http://www.mysql.com/about/legal/licensing/foss-exception.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd problems
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client
Library) support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
--
http://blog.ulf-wendel.de
Artikel zu den Sun MySQL-Connectoren für PHP, C++ und OpenOffice.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enable mysqlnd as default backend (not about enabling mysql by default)
Jani Taskinen schrieb: Pierre Joye kirjoitti: Hi, Would it not easier and better to have mysqlnd as default backend for the mysql extensions (pdo, mysqli and mysql) when the configure option are used without value? I can already imagine the maintenance pains and the debugging nightmare for our users while working with a buggy libmysql instead of mysqlnd. Current status of mysqlnd does not warrant it being default. Just check the bug database.. I would appreciate if the bug database could distinguish between feature requests and bugs. Ulf -- http://blog.ulf-wendel.de Artikel zu den Sun MySQL-Connectoren für PHP, C++ und OpenOffice.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd as a shared extension ?
Remi Collet schrieb: My goal will be to provides both solutions (libmysql and mysqlnd) to be able to quickly switch from one to the other (for tests / benchmark) Any idea / solution ? Andrey might have. CC'ing him. P.S. main question is probably, should we use mysqlnd under linux ? Depends who you ask. If you ask me, go for it. If you don't, it remains untested forever. untested? Well not really. We never had that many tests before. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Jille Timmermans schrieb: I have 'implemented' MySQL's mysql_warning_count() function. ( http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html ) mysql_warning_count() is available in MySQL's C-api in 3.23, 4.1 and 5 I am not a big fan of adding anything to ext/mysql that is not security relevant or mission critical. mysql_warning_count() is a convenience function. Let ext/mysql run out and use ext/mysqli instead. ext/mysqli is around since PHP 5.0 = 2004 = 5 years. It can be considered as faily stable. It is as easy to use as ext/mysql. Performance is virtually identical. Only ext/mysqli gives you access to all functionality of MySQL 4.1 and above, e.g. charset and prepared statements. I see no reasons for updating ext/mysql when there is a successor (for so long). Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Jille Timmermans schrieb: Only ext/mysqli gives you access to all functionality of MySQL 4.1 and above, e.g. charset and prepared statements. Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. ext/mysql already hides functionality, for example, prepared statements. If you add all the missing pieces to ext/mysql you get ext/mysqli... Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Alexey Zakhlestin schrieb: On 13.10.2009, at 16:10, Jille Timmermans wrote: Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. Definitely +1 from me. As long as ext/mysql is bundled with php (which means officially supported) I see no reason to reject simple patches Definetly -1 from my side: what maked warning count different from prepared statements? If ext/mysql would not have such a tremendous user base, I would even suggest to disable it by default. Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 11.2012 14:00, schrieb Adam Harvey: I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. Adam, I am more than happy someone who is not paid by MySQL took the time to write an RFC. I/we have been trying to sing the stop using ext/mysql-song since at least since 2006. We put ext/mysql in a (security) bug fix maintenance mode only years ago. Too many ignore those attempts to get rid of ext/mysql. I searched a major search engine for PHP MySQL tutorials a few months ago. 9 out of the top 10 search results demonstrated how to use ext/mysql. 90% are of the tutorials are ashaming junk in my eyes. Wake them up. The year 2013 is just around the corner... However, because of the documentation situation, we waited and waited. You initiative seems to show that the deprecation message has finally reached circles outside MySQL. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 12.11.2012 15:48, schrieb Antony Dovgal: On 2012-11-12 18:15, Adam Harvey wrote: I don't think the documentation is necessarily effective here, particularly with functions that users tend to know by heart skip I'm not really convinced the average user ever looks at the manual for things they know, truth be told. Well, I'd expect people actively developing applications in PHP to use the docs from time to time. But my concern is for people using legacy apps. True, they might not use the docs at all and the only warning they'll get when they do their usual PHP upgrade is error logs stuffed full of E_DEPRECATED. So what is they going to do in that case? Disable the notice, of course. Don't bother. There is a standard way of deprecation, at least I assume there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 16.11.2012 03:23, schrieb Sherif Ramadan: People have been talking about and educating others about the deprecation of ext/mysql for quite some time now. I'm sure that it Random dates in the lifes of ext/mysql[i]: 2003 * ext/mysqli, the improved version of ext/mysql gets developed * Int. PHP Conference ext/mysqli talk * Similar talk given at the local PHP meetup in Hamburg includes Migration from mysql to mysqli * Zak Greant and Georg Richter publish Zend.com article 2004 * PHP 5.0.0 ships ext/mysqli * 2x Int. PHP Conference PHP5 + MySQL 4.1/5.0 (= requires ext/mysqli, mysqli was made for 4.1/5.0) * ApacheCon Europe PHP5 + MySQL 2006 * MySQL recommends mysqli and publishes a conversion script http://lists.mysql.com/announce/400 * ext/mysql feature request gets won't fix https://bugs.php.net/bug.php?id=37867 * MySQL announces the plan to develop the mysqlnd library 2007 * First public mysqlnd version supports mysqli only http://lists.mysql.com/announce/432 ... 2011 * Public ext/mysql deprecation outcry 2012 * Soft-deprecation warnings added to php.net manual https://bugs.php.net/bug.php?id=62213 No judgement intended. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 13.11.2012 04:08, schrieb Adam Harvey: On 13 November 2012 08:44, Christopher Jones christopher.jo...@oracle.com wrote: Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 20.11.2012 11:22, schrieb Lester Caine: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This is no argument for adding this specific old wiki stuff to the RFC, is it? However, I reckon your proposal. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 20.11.2012 13:25, schrieb Lester Caine: Ulf Wendel wrote: Am 20.11.2012 11:22, schrieb Lester Caine: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This is no argument for adding this specific old wiki stuff to the RFC, is it? However, I reckon your proposal. In the absence of nothing better? Lester, you may want to read the fine manual: http://www.php.net/manual/en/mysqli.quickstart.php Ideally someone who knows mysqli inside out needs to update these documents ... I'll stick to converting mysql users to Firebird :) Are you aware of what you do to the discussion and the list? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC mysqlnd.localhost_override
Am 12.02.2013 12:51, schrieb Asbjørn Sannes: https://wiki.php.net/rfc/mysqlnd_localhost_override I propose we introduce a new option called mysqlnd.localhost_override which enables a system administrator or php distributor to configure how localhost should be overridden. localhost meaning is a MySQL legacy (http://dev.mysql.com/doc/refman/5.6/en/connecting.html). I am no big fan of redefining the meaning of a standard MySQL legacy setting at library level as it will confuse many users. Why are the existing API level configuration settings mysqli.default_socket respectively pdo_mysql.default_socket not enough? php -d mysqli.default_socket=/tmp/mysql56.sock -r '$mysqli = new mysqli(localhost, root); var_dump($mysqli);' Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC mysqlnd.localhost_override
Am 12.02.2013 13:11, schrieb Johannes Schlüter:
On Tue, 2013-02-12 at 12:51 +0100, Asbjørn Sannes wrote:
https://wiki.php.net/rfc/mysqlnd_localhost_override
I propose we introduce a new option called mysqlnd.localhost_override
which enables a system administrator or php distributor to configure how
localhost should be overridden.
The localhost behavior is already confusing enough. If you want to
have such behavor for your system I suggest a plugin like described in
http://schlueters.de/blog/archives/146-mysqlnd-plugins-for-PHP-in-practice.html
but not as a core feature.
Abusing PECL/mysqlnd_ms is also possible...
nixnutz@linux-0v4u:~/php-src/pecl/mysqlnd_ms/trunk/examples cat s1.json
{
localhost: {
master: {
alias_name: {
host: 192.168.2.28,
port: 3306,
db: test
}
},
slave : {}
}
}
nixnutz@linux-0v4u:~/php-src/pecl/mysqlnd_ms/trunk/examples php -d
mysqlnd_ms.enable=1 -d mysqlnd_ms.disable_rw_split -d
mysqlnd_ms.force_config_usage=1 -d mysqlnd_ms.config_file=s1.json -r
'$mysqli = new mysqli(localhost, root);
var_dump($mysqli-query(SELECT 1)-fetch_assoc());
var_dump($mysqli-query(DROP TABLE IF EXISTS test));
var_dump($mysqli-host_info);'
array(1) {
[1]=
string(1) 1
}
bool(true)
string(23) 192.168.2.28 via TCP/IP
Ulf
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autotests: Access denied for user 'root'@'localhost' (using password: NO)
Am 18.08.2011 00:46, schrieb Reindl Harald: Wouldn't it be a good idea to specify here a user/pwd/database for build-systems without force them open root without password? SKIP mysql_get_host_info() [ext/mysql/tests/mysql_get_host_info.phpt] reason: Can't connect to MySQL Server - [1045] Access denied for user 'root'@'localhost' (using password: NO) Please, configure the tests to use whatever database user you want them to use prior to running. If nothing else is configured, the tests need to make a guess on the on the DB credentials. The guess is user=root, password= as such a DB account is available when doing, for example, a source installation of MySQL. Have a look at http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/mysql/tests/connect.inc?revision=296885view=markup . It tries to check the environment for variable to allow for easy configuration but ultimately has some defaults in it. This is a common pattern, for example, check http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/oci8/tests/details.inc?revision=312024view=markup . If no configuration done through environment settings, OCI8 tests default to DB user system, password oracle - whatever user that is. grep -R getenv ext/*/tests/*.inc - ext/ldap - ext/mysqli - ext/mysql - ext/oci8 - ext/pdo_mysql - ext/pdo_pgsql - ext/pdo - ext/sybase grep -R getenv ext/*/tests/*.phpt - ext/curl - ext/pdo_pretty_much_all_of_them A potential pitfall that affects all test writers trying to allow configuration via environment settings is the - certainly sensible - variables_order setting found in php.ini-development and php.ini-production. php.ini-development:variables_order = GPCS php.ini-production:variables_order = GPCS If any of the two is used as a configuration file for running tests through run-tests.php, run-tests.phpt will not be able provide tests with all environment variables, http://lxr.php.net/xref/PHP_5_3/run-tests.php#140 . run-tests.php relies on $_ENV and $_ENV is empty. To make a long story short: tests may require manual configuration prior to running. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TameJS syntax for Async/Parallel execution in PHP
Am 19.08.2011 13:12, schrieb Jonathan Bond-Caron:
On Thu Aug 4 09:54 PM, Raymond Irving wrote:
Hello,
I came across this little library called TameJS (http://tamejs.org/)
and fell in love with the it's syntax. This had me thinking if it was
possible to add such features to a PHP CLI (or web app):
Thanks for sharing, never heard of tame. Love the await{} block
await {
mysql_query_async($sql, $args, defer($rs));
curl_post_async($url,$data, defer($response));
}
$rows = $rs-fetchAll();
http://de.php.net/manual/en/mysqli.query.php
[...]
With *MYSQLI_ASYNC (available with mysqlnd)*, it is possible to perform
query asynchronously. mysqli_poll() is then used to get results from
such queries.
[...]
PG should have similar functionality.
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: [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: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 02.09.2011 21:24, schrieb Stas Malyshev: Hi! On 9/2/11 12:17 PM, Christopher Jones wrote: I'm +1 for this. I think the decision implementation needs to be done before Beta or deferred to trunk. Frankly, I'd be more comfortable with trunk. We have enough trouble with unit tests etc. before the beta, and introducing profound change in default without enough time for discussion and gathering feedback from packagers, etc. doesn't look a smart thing to do. Hmm, I do not understand the unit test argument. Non-portable tests exist regardless of what the config.m4 default is. We are talking about making mysqlnd as a compile default, if not explicitly choosing libmysql to compile against. This is no attempt to remove libmysql support. I somewhat assume most packagers do explicitly set libmysql path already and do not rely on any magic, because they don't use MySQL's default source layout. However, argument taken, let's do some checks who (Debian, Ubuntu, OpenSuse, RH, ...) does not set libmysql path during compile. mysqlnd was introduced with PHP 5.3. IMHO, it has matured quite well. Mysqlnd reduces the PHP projects dependency on anybody controlling the library. This has been a major pain in the past. Think of builds made against outdated versions of libmysql, think of waiting for new libmysql releases, think of compilers not supported by libmysql, think of license discussion, think of accepting code contributions and so forth. From a user perspective mysqlnd removes the need to install libmyql prior to building and a has a couple of neat features not available with libmysql, for example, the plugins. Ulf -- 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
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 02.09.2011 22:17, schrieb Lester Caine: Rasmus Lerdorf wrote: I was actually going to suggest doing this in 5.4 and trunk but didn't get around to writing the email yet. It would still be nice to be able to simply switch off MySQL for those of us who do not have it installed ... It gets annoying when PHP forces the installation of MySQL in a distribution and then prevents disabling it. It is another example of why a more modular approach does make sense! Lester, do I understand that you are afraid of a PHP which comes with MySQL support that cannot be disabled? I don't think the proposal goes like that. The proposal is to change the default library, if not set during compile, used by the MySQL extensions, if enabled, from libmysql to mysqlnd. This is independent of the questions: - if any MySQL extension shall be enabled by default - if PHP can be built without MySQL support And, I said it in the other email, this is no attempt to remove libmysql support. I may be wrong but your concern - as valid as it is - seems a bit off topic, no? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 02.09.2011 22:57, schrieb Johannes Schlüter: On Fri, 2011-09-02 at 22:48 +0200, Ferenc Kovacs wrote: On Fri, Sep 2, 2011 at 10:44 PM, Stas Malyshevsmalys...@sugarcrm.com wrote: Hi! On 9/2/11 1:41 PM, Ferenc Kovacs wrote: I think you missed the referenced [1]: [1] Yes, we will still allow building with libmysql and we will fix bugs reported there and we will verify it works but focus on mysqlnd, as we're actually handling it already I did not miss it - I do not see what it means. Either we support both - and then for the matter of development and testing nothing changes - or something changes, namely we remove one moving piece out of the test equation, the moving piece being libmysql - and remove means remove. I just don't see how you can have both of these things at the same time. I think that Johannes means that mysqld would be the preferred or baseline for the mysql tests. maybe supporting IE6 would be a good metaphor: you could say that you support every browser equally, or you could say that you write your stuff for the modern browsers and tests it against IE6 and fix where necessary. Johannes, is this what you had in mind? Thanks, I like your analogy and don't have a better one. Let's see if I get it right. Johannes and I say: - libmysql support is there and it will stay there - libmysql shall continue to be supported - tests shall be written in a portable way, whenever possible We furthermore said, let me put it straigt: - we failed to catch some libmysql/MySQL/test version combination portability issues - shit happens, sorry for that - testing any extension that has external dependencies is a pain I think, such a statement is quite a big step towards your test concerns, Stas. Ultimately, I still don't get what you (Stas) are after with the test discussion. Have I missed any of your worries? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 02.09.2011 23:20, schrieb Stas Malyshev: Hi! On 9/2/11 1:57 PM, Johannes Schlüter wrote: maybe supporting IE6 would be a good metaphor: you could say that you support every browser equally, or you could say that you write your stuff for the modern browsers and tests it against IE6 and fix where necessary. Johannes, is this what you had in mind? Thanks, I like your analogy and don't have a better one. That is exactly the problem - *nobody* says we support every browser equally and most sites/applications explicitly say we do not support IE6 and every bug on IE6 is rejected unless it happens in some other place. If you plan to give libmysql the same treatment it means removing support for it, plain and simple. If you mean something else, please explain. Stas, what is not clear from my last mail? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 02.09.2011 23:30, schrieb Stas Malyshev: Hi! On 9/2/11 2:12 PM, Ulf Wendel wrote: I think, such a statement is quite a big step towards your test concerns, Stas. Ultimately, I still don't get what you (Stas) are after with the test discussion. Have I missed any of your worries? My concerns is first and foremost to have unit tests passing and compatibility API issues sorted out - such as same functions producing different semantics on libmysql and mysqlnd. This is my primary concern, especially if we want to have beta anytime soon :) Stas, if you are really concerned about tests, aren't you a bit late, are all the 5.3 releases to be considered instable. I mean, they use the same tests. Andrey may know better, but I even assume mysqlnd to be very, very similar in 5.3 and 5.4. How strong is your argument, how many critical differences are you aware of that prevent a config.m4 change? If there are criticial differences of much practical relevance, how could we miss them, why are we not seeing more bug reports? With all given respect, I think you are going a bit far here. You seem to be extrapolating from test x does not work in configuration y to z is instable/incompatible with y. You have one argument against the config.m4 change that I get - the packaging/distribution one. But the test does not pass with X/Y/Z_old seems a bit weak to me. I hope, nobody is angry if I call it a day. Enjoy the weekend, Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 03.09.2011 03:51, schrieb Rasmus Lerdorf: On 09/02/2011 06:08 PM, Stas Malyshev wrote: Hi! On 9/2/11 6:02 PM, Rasmus Lerdorf wrote: Well, we are not trying to get to 0 failed tests in all permutations of all extensions on all platforms. We are trying to get to 0 failed tests on a common-case build using defaults and common extensions. Given that, changing a default has an impact on the 0-failed-tests goal. Nobody talks about all permutations of all platforms, let's not be absurd here. However, there's a distance between all permutations of all platforms and we'll be ignoring failures on libmysql. libmysql *is* the common case build and the one most people would be running in production, at least as far as I see around. Ah yes, but is that because they have actively chosen to use libmysql or is it because our default is libmysql. It is buggier and less robust than mysqlnd at this point, at least in my experience, so who are we helping by leaving libmysql as the default? ACK. Yes, it is about the default that others copy from php.net. (Yes, I consider mysqlnd stability to be at least on par with the libmysql and, mysqlnd is usually getting much faster bug fixes. Together with the set of free PHP license plugins (pecl/mysqlnd_*, query cache, replication support, load balancing, monitoring, ...), asynchronous/non-blocking queries, a nice debug trace log, copy-on-write variables, recognition of PHP's memory limit, ... it is worth a recommendation to users. Time to spread the news by switching the compile default. Five years after development started, four years after alpha and beta. Plus the PHP 5.3-series as an incubation time.) Forget the failed tests. A new PHP release is about improving the ecosystem. If the folks that maintain libmysql and mysqlnd suggest that mysqlnd is more robust and it is the path forward, why would we resist this? Do we not trust Oracle/MySQL enough to listen to their input? ACK. (For the last time in this thread: there are no plans to remove libmysql support but mysqlnd is the recommended choice.) Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysqli tests breaking
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=0limit=Allorder_by=iddirection=DESCcmd=displaystatus=Allbug_type=Allphp_os=phpver=cve_id=assign=author_email=bug_age=0bug_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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysqli tests breaking
Am 05.09.2011 11:37, schrieb Stas Malyshev: Hi! On 9/5/11 2:29 AM, Ulf Wendel wrote: - BC breakage is impossible because behavior is undefined - update test, issue gone OK, since you say it's not the intended behavior to be relied upon, I'll remove this check from the test (if nobody beats me to it). No, please don't change it that way. Returning a relevant value for stmt_num_rows() seems a valid feature request that makes perfectly sense to me and is somewhat in line with the vague non-PS documentation of the case. To the end user the message is undefined, do not rely on. Towards the library implementor the message is try to make libmysql become better in the future, keep reasonable value in mysqlnd implementation meanwhile. Do something like: if ($IS_MYSQLND) /* TO END USER: no promise on this assumption */ ... Please, do not drop the information of the difference by removal of the assertion. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysqli tests breaking
Am 05.09.2011 12:00, schrieb Stas Malyshev: Hi! On 9/5/11 2:49 AM, Ulf Wendel wrote: Returning a relevant value for stmt_num_rows() seems a valid feature request that makes perfectly sense to me and is somewhat in line with the vague non-PS documentation of the case. It's not a good situation where mysqlnd and libmysql have different semantics and people are encouraged to rely on it (if you call it feature, you encourage people to use it, otherwise why call it feature?). It leads to code that works on mysqnd but not on libmysql, without any indication of it - you'll just install an app, and it would Well, those who want to reply on UNDEFINED behavior, shall fool themselves. It will be a great laugh for the rest of us. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
[PHP-DEV] SKIIP of FAIL for tests depending on external bugs
Am 05.09.2011 15:28, schrieb Andrey Hristov: On 09/05/2011 03:19 PM, Ulf Wendel wrote: ... 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 Andrey, you are changing topic from MySQL something test failure to test writing in general. IMHO you are raising a general question worth a dedicated discussion thread, something like: If a test depends on external entity, which has a bug, shall the test FAIL or be SKIPPed? I'd appreciate if this is discussed independently of the example of a mysqli test failure discussed in the light of the upcoming PHP 5.4 beta. Ulf -- 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
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] Make mysqlnd default over libmysql in 5.4
Am 05.09.2011 11:08, schrieb Stas Malyshev: Hi! On 9/5/11 1:24 AM, Andrey Hristov wrote: the problem is that libmysql breaks, maybe more often than mysqlnd does. We rarely find bugs in mysqli, there are two codepaths in mysqli. If there is a bug in libmysql, what do you want: If we're dealing with libmysql bug, then I guess the expected thing would be to report it upstream, and make the comment in the test with bug ID. But in the cases I mentioned it does not look like libmysql bug as everything works just according to Mysql documentation, however the tests expect it to work differently. Stas, what are we going to do now after the discussion has calmed down a bit? Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an incubation of some four years (5.3x series + dev time). You, in your role as 5.4 RM, raised some concerns about changing the default to mysqlnd. Your primary concern is rolling out something that breaks PHP. As an example, you have listed some mysqli test failures. After the weekend, I'm a lazy bastard refusing to work during weekends, test failures have been commented on: - connect_oo_* - libmysql only, no BC [1] - explain_meta - libmysql can crash PHP, mysqlnd works [2] - stmt_num_rows - differences in undefined behaviour [3] - insert_id - as a bug, it would be bogussed, undefined [4] Your four examples stand up against, for example, Pierre Windows Joye. The php.net windows binaries are using mysqlnd as of PHP 5.3. Windows is probaly the biggest individual distribution. Pierre, who is no MySQL fan boy, reports no BC issues. This is based on multiple years of php.net Windows users feedback and his continous integration testing using drupal 67, wp, oscommerce, mediawiki, sugarcrm, etc. [5]. At least on Windows, users do expect to see mysqlnd meanwhile. Harald Reindl did the switch from libmysql to mysqlnd on hundret domains with no single problem [6]. OpenSuSE did the same. As a manager, you often have to make a decision without knowing all details, without checking everything yourself. You have named and set the #1 risk (BC) and heard people's opinion: mysqlnd is not flawless, but well worth a try. You also raised the question how or if a change will impact packagers. Tomas Kuliavas gave some great input on this [7]: SuSE: --with-mysql=shared,mysqlnd Debian, Mandriva and Fedora: --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config' Looks like packages explicitly set config options. Thus, no break provoked if changing defaults. There's a bit of a buzz on shared builds, Johannes is working on that one - https://bugs.php.net/bug.php?id=55609 . IMHO all of the relevant concerns have been adressed. No high risks have been found. There is nothing in the way that cannot be tackled down as one moves forward. I see no reason for ignoring the vote of the maintainers. I fail to understand why PHP @ *nix should not catch up to Windows. Ulf [1] http://news.php.net/php.internals/55226 [2] http://news.php.net/php.internals/55221 [3] http://news.php.net/php.internals/55210 [4] http://news.php.net/php.internals/55228 [5] http://news.php.net/php.internals/55177 [6] http://news.php.net/php.internals/55174 [7] http://news.php.net/php.internals/55142 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Borked SKIPIFs (PHP_5_4)
Hi,
annoyed by run-tests.php ignoring borked SKIPIF sections, I hacked it to
bail out at me if something seemed suspicious. Maintainers may want to
have a look at:
Fatal/Parse error @ SKIPIF = SKIPIF non functional
BORK 883/9126 [Zend/tests/bug31683.phpt]
BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
Warnings/Notices @ SKIPIF = SKIPIF should work fine
BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt]
BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt]
BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt]
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
My PHP was built with pretty much nothing but MySQL stuff enabled. A
fair number of tests has probably been skipped.
The run-tests.php hack I used is not worth sharing. All I did was check
if SKIPIF returns any output after removal of -d display_errors=0. In
other words I made the assumption that SKIPIF sections must not output
anything but skip message or the like, which causes false positives.
Ulf
Details:
BORK 883/9126 [Zend/tests/bug31683.phpt]
Warning: require_once(skipif.inc): failed to open stream: No such file
or directory in
/home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php
on line 1
Fatal error: require_once(): Failed opening required 'skipif.inc'
(include_path='.:/usr/local/lib/php') in
/home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php
on line 1
BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt
Fatal error: Call to undefined function php_version() in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/phar/tests/fopen_edgecases2.skip.php
on line 2
BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt]
Notice: Use of undefined constant posix_getpgid - assumed
'posix_getpgid' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_error.skip.php
on line 2
[] ext/posix/tests/posix_getpgid_error.phpt
BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt]
Notice: Use of undefined constant posix_getpgid - assumed
'posix_getpgid' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_variation.skip.php
on line 2
BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt]
Warning: PHP Startup: session.upload_progress.freq must be greater than
or equal to zero in Unknown on line 0
BORK 4866/9248 [ext/session/tests/rfc1867_invalid_settings_2.phpt]
Warning: PHP Startup: session.upload_progress.freq cannot be over 100%
in Unknown on line 0
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
Warning: include(skipif.inc): failed to open stream: No such file or
directory in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php
on line 1
Warning: include(): Failed opening 'skipif.inc' for inclusion
(include_path='.:/usr/local/lib/php') in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php
in line 1
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
Parse error: syntax error, unexpected '!', expecting '(' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/md5_file.skip.php
on line 6
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
Parse error: syntax error, unexpected '!', expecting '(' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/sha1_file.skip.php
on line 6
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Borked SKIPIFs (PHP_5_4)
Hi Pierre, hi all, those three should be left: BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] They might take more than 1 second (verbally) to fix. Leaving to someone else to have a 30 seconds look... ;-) Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 06.09.2011 21:33, schrieb Stas Malyshev: Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an incubation of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it now. Jippie! Removing libmysql support would be crazy. Not only from a PHP perspective but also from a MySQL one. For PHP it is a must-have fallback option. For MySQL the PHP stuff is a nice libmysql test drive. Not a welcome job among the mysqlnd fan boys, as you noticed. But then, sometimes we count mysqlnd vs. libmysql issues... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Harcoded mysql.sock path in mysqlnd extension
Am 16.01.2012 11:19, schrieb Remi Collet: P.S. well, don't know if having such a hardcoded path is a good idea... mysqlnd is a libmysql drop-in replacement. Guess what libmysql does... - do strings libmysqlclient.so | grep mysql.sock on a standard source build. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
On Fri, 2011-11-18 at 16:06 -0500, Daniel Convissor wrote:
The length property is what's tripping up my unit tests. I'm building
PHP 5.4 from svn for both tests. The only difference between them is
the with-mysqli declaration. Here is a table summarizing the situation:
type libmysql mysqlnd
---
TEXT 65535 196605
CHAR(2) 26
Is this intended behavior?
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd libmsql) is the same if you mind
the character set (use SET NAMES etc.)
ACK, likely a bogus report.
MySQLnd always assumes the server default charset. This charset is sent
during connection hand-shake/authentication, which mysqlnd will use.
Libmysql uses the default charset set in the my.cnf or by an explicit
call to mysqli_options() prior to calling mysqli_real_connect(), but
after mysqli_init()., http://www.php.net/manual/en/mysqli.construct.php
Ulf
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Am 19.01.2012 20:27, schrieb Daniel Convissor: Gentlemen: On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote: Am 19.01.2012 13:50, schrieb Johannes Schlüter: Your server seems to be configured for UTF-8 by default. In my tests the behavior for both libraries (myslqnd libmsql) is the same if you mind the character set (use SET NAMES etc.) Yes, my server is set to UTF-8 in my.cnf: character-set-server = utf8 MySQLnd always assumes the server default charset. This charset is sent during connection hand-shake/authentication, which mysqlnd will use. Libmysql uses the default charset set in the my.cnf or by an explicit call to mysqli_options() prior to calling mysqli_real_connect(), but after mysqli_init()., http://www.php.net/manual/en/mysqli.construct.php From the documentation exceprt, above, the test code in https://bugs.php.net/bug.php?id=60333 should be using the server's default character set under both mysqlnd and libmysql. So shouldn't they both come back with the same answer? Or am I misunderstanding something? mysqlnd simply does not read MySQL server config. It defaults to actual connection of the server. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions
Am 24.04.2012 14:27, schrieb jpauli: I understand your thoughts, but I disagree as I think it would be much more clean to expose it via mysqlnd_***() API than through each MySQL ext (and for PDO that would be even more dirty). That would as well add more and more #ifdef MYSQLND inside their source... I was thinking the same way libxml2 API is provided inside ext/libxml instead of through each PHP XML extension API. A fourth MySQL API is not my goal. There's enough confusion with three of them already. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 15.06.2012 03:01, schrieb Anthony Ferrara: I raised this topic on list over a year ago ( http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was determined that it wasn't time yet to disable prepared statement emulation for MySQL yet. However, Rasmus did mention that it was a possibility for 5.4 ( http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that ship has sailed, I submitted a pull request for trunk to change the default value of prepared statement emulation for MySQL. https://github.com/php/php-src/pull/108 https://bugs.php.net/bug.php?id=54638 Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? Please, be aware of the consequences of this move and don't break any tests. Also, please, do no break it down to prepared statement === security as any such _short_ statement draws an incomplete picture and bares more risks than it does good. Back then, Johannes already pointed out some consequences: http://marc.info/?l=php-internalsm=130423522001744w=2 . Here's another iteration on the topic. There are assorted others in my blog from the days PDO_MySQL has seen its last major update. *Security* It is claimed that native prepared statements are more secure because: - statement and parameter are send to the server independently - the server builds the final statement string Whereas for a non-prepared statement: - the client builds the final statement string - the client has to escape parameter values - the client sends statement and parameter in one As long as client-side escaping is done properly, there is no practical difference between the two approaches. There are, however, arguments that boil down to limiting the possiblity of user errors: - bind-style API - messing up on charsets A bind-style API may be convenient and prevent forgetting to use escaping but does not prevent to shoot yourself doing something foolish such as: PDO::query(... . $_REQUEST['killme']); When using non-prepared statements it must be ensured to use the correct charset for (client-side) escaping. As long as charset changes happen through API calls, the client library is always aware of the current charset and everything is fine. But, the charset can be changes through SQL as well: SET NAMES ... The fact that PDO lacks API calls to set the charset, which enforces the use of SET NAMES, is not helpful. However, even with appropriate API calls users can always fool themselves using: PDO::query(SET NAMES) If building the final statement is done on the server or SET NAMES is disallowed, fooling yourself becomes much harder. *Security in the context of PDO* Actually, the change of the default can give you a false feeling of improved security. This is due to the design of PDO and the existance of a prepared statement emulation in the core of PDO. A statement like this will use the prepared statement emulation: SELECT something FROM table WHERE cond = :placeholder MySQL does not support named bind parameter such as :placeholder. The PDO parser kicks in and does replace :placeholder with the bound value. Which then, is no different from: sprintf(SELECT something FROM table WHERE cond = '%s', escape($param)) Of course, escape() can't be forgotten. It happens inside PHP, inside PDO on the C level. Messing up with charsets is still possible. Thus, users must be educated as ever since. The message prepared statement === security is too short to tell the full story. BTW, there's the classic of: SELECT something FROM table LIMIT :placeholder What will happen if forget to hint a data type for :placeholer? Search the bug database, if you can't answer. As you are at it, try the reverse with ? and another database system that does not support ? as a placeholder... *Performance (and impact on server load)* After switching to native prepared statements users may see an increase of MySQL - PHP round trips: prepare() client -- server execute() client -- server Great, if statements get executed multiple times. Bad, if statements are not executed multiple times, such as: SELECT title, received FROM news WHERE = SELECT name, price, special_price FROM specials Those statements will take two round trips, thus become slower. Things become slower although there is no other win. Note, that none of the example statements has any parameters. A statement such as: INSERT INTO test(col) VALUES (?) May become faster if multiple rows are inserted. The statement string is transferred only once during prepare. Later only the parameter value is transferred. But, of course, you'd use MySQL multi-insert syntax or other tricks here anyway, wouldn't you? Back in the 70's, when prepared statements have been introduced, the world was a different one. Prepared statements make the assumption that its benefitial to cache various things, such as query execution plans, inside the database server.
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 15.06.2012 18:36, schrieb Anthony Ferrara: Chris, Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? It needs an RFC because it needs to document whether or not the other DB drivers should also be changed. It's a PDO driver-specific change. So to me it's fairly straight forward to see that no other drivers need changing... It doesn't even hit the mysql API level... Not saying an RFC isn't needed, just that justification isn't clear to me... Go commit if you feel like the change is widely accepted, you are willing to explain the differences to users and no test breaks. After all its a tiny, little PDO driver default setting. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 15.06.2012 19:31, schrieb Anthony Ferrara: Ulf, It needs an RFC because it needs to document whether or not the other DB drivers should also be changed. It's a PDO driver-specific change. So to me it's fairly straight forward to see that no other drivers need changing... It doesn't even hit the mysql API level... Not saying an RFC isn't needed, just that justification isn't clear to me... Go commit if you feel like the change is widely accepted, you are willing to explain the differences to users and no test breaks. After all its a tiny, little PDO driver default setting. I think you interpreted me wrong. I was just pointing out that this change would be localized to the PDO_MySQL driver. And that documenting whether other DB drivers should be changed is a moot point, since they already aren't using emulation by default... And where did the passive-agressive thing hit off? I posted it to list There's a bug/feature request. Not just one, many came up over the years. You wrote a patch. You proposed a change. Nobody rejected the change - for a year. Its a tiny change of a driver default setting. It does not require an RFC. One of the maintainers, me, didn't bring up any objections. I said what any maintainer has to say: - educate users, be aware of the consequences - make sure not to break any tests Another maintainer, Johannes, didn't say no a year ago. Nobody says no, !no ~ go - its your call. Stand in for your proposal, take care of the tests and commit. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
No worries, Anthony! Am 15.06.2012 21:15, schrieb Anthony Ferrara: I would commit, but I do not have commit access (no karma at all). I'm going away for a few days, but when I get back I will send a separate request to the list for karma. I see. It is not up to me to grant karma. I am not that active in the PHP project and wouldn't even want to have the power to give you karma. Those that have the power, shall decide. The key for me is: ... you stand in for the change ... you are aware of the technical aspects ... you are willing to help ... you waited for a long time and drove discussion - you must have a reason... Who does the commit is of little interest to me. You, I or Johannes can do it the other day. You can expect us to support the new default and not fall in your back but regarding the change itself, I'm no more than +/- 0. You'll have to continue to stand in if a discussion comes up. Deal? n8 enjoy your weekend, Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 15.06.2012 18:28, schrieb Christopher Jones: On 06/15/2012 08:34 AM, Ulf Wendel wrote: As long as client-side escaping is done properly, there is no practical difference between the [client vs server -prepare] approaches. The big problem with this line of reasoning is that the client must know exactly the same dialect of SQL/XQUERY/whatever that the server does. Since we can't predict the future, and so a new DB might Plain wrong. If client does not mess up on type and charsets there is no practical difference between the security of properly done client side escaping and server-side escaping. No matter if the subject of escaping is a fairy tale on goofy or any other string that happens to look like any other human invented format, e.g. SQL. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 20.06.2012 08:39, schrieb Pierre Joye: hi Chris, On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones christopher.jo...@oracle.com wrote: We should take this offline - I can see cases where I'd strongly disagree. I see no reason to move a discussion offline or off list, this is a topic that interests many other readers or developers. Agreed. There was enough trouble around PDO and discussions going on in the hidden. However, this does not impact the original topic. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Jani Taskinen schrieb: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? It is doable, likely desired but it is going to be a bit of work. What you save is the work of having to update multiple branches manually. What you risk is that not each and every test is prepared for being run with every version - although, maybe, in theory it should be. This is certainly something that can be solved by adding some more magic to run-tests.php, e.g. ==SKIP-VERSION== as suggested by Hannes - practicalities. Also, you may end up shipping the same huge set of tests for every PHP version regardless if all tests you ship are compatible with that version. Again, some magic should solve that - practicalities. There is one thing I fear, although it is desired to do. Many extensions link external libraries. If you throw all tests in one place and run all tests with all PHP versions, I strongly assume you'll get more reports on test failures. That is because the likeliness of someone out there running new tests designed for the latest version of an external library against an old library will increase. Yes, you want to know about any such incompatibility. Yes, it helps you making your software better. But it may mean significantly more work in particular if you follow the common paragidma of test ample must always be green at any time on every system. What may cure the extra work problem is to be more strict on compatible versions. I am aware how much people love BC. But there's a point where keeping BC should be left as an exercise to those asking for BC. All in all, I like the idea but I fear extra work. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Jani Taskinen schrieb: What you risk is that not each and every test is prepared for being run with every version - although, maybe, in theory it should be. This is It should not be theory for regression tests? If new release does not pass the old tests but the old versions still do, then it's quite likely the new version is buggy? Now we have different versions of same tests in each branch (in the worst cases) and thus the behaviour might really be different between them when it should not be. I am with you on the idea of a central repository and the arguments behind your two questions. Though, you know, I'm lazy and I fear you really find issues that need to be fixed :-) . For a transition period there's likely to be more work and the number of test failures is likely to go up. That is nothing to really worry about as long as you manage to educate users that it is not a quality defect of PHP as such but a temporary matter of an different and improved testing approach. There is one thing I fear, although it is desired to do. Many extensions link external libraries. If you throw all tests in one place and run all tests with all PHP versions, I strongly assume you'll get more reports on test failures. That is because the likeliness of someone out there running new tests designed for the latest version of an external library against an old library will increase. This part I didn't quite understand..isn't this same issue with the current situation as well? Its only a diffuse feeling of mine, I could well be wrong. In any case I am not trying to argue against your proposal. Just the opposite. Let's assume the worst case status quo of different versions of the same test in each branch. The one in an old branch has been written with the versions of the external library in mind that has been current when the branch was current. The one in a current branch has been written against the latest version of the external library. I continue to assume that users of the old PHP branch run rather old systems whereas users of a current PHP branch run on current systems. Therefore only few people may have tried to run the old test against the latest library or the other way around. It is just a feeling that your proposal will implicitly cause some combinations of PHP version x test x external library version to be tested that have not been checked before. Your one test for all proposal is likely to unveil some different versions of the same test and external library is not BC issues. That's good. But its gonna be work... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Johannes Schlüter schrieb: As I said before in this thread: Realistically we can't drop it. Too many tutorials, books, applications, ... mention mysql_* and ignore the limitations and issues the old mysql extension provides... True, true... One of the best things one can do is to bash very article, blog posting, mailinglist posting and in particular every recent book showing ext/mysql examples instead or either ext/mysqli or PDO_MySQL examples. Every now and then we get feature requests for ext/mysql through bug reports. The reporters often complain badly if we MySQL guys refuse to add the requested feature to ext/mysql ... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Johannes Schlüter schrieb: On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: Am 19.06.2010 11:33, schrieb Patrick ALLAERT: What are the possible actions/alternatives? I think this was already mentioned: add a BC layer to ext/mysqli so that the new extension supports the old mysql_* functions. This would rid us off the old ext/mysql code without breaking code that relies on it. ... while such a wrapper has about the same amount of code as the classic mysql extension (... which is in most parts a simple wrapper over library functions...) Or in other words: Such a wrapper doesn't have real benefits. And any wrapper which is there by default won't change anything. People will continue to use the old API. You need to move the masses or create facts by removing ext/mysql. The latter is quite crazy considering how popular ext/mysql is. Its popularity is somewhat understandable: its old and the API is very phpish in a classical non PJAVA sense. One of the few things that could be done is adding a note to each and every ext/mysql docs page stating that one shall use ext/mysqli instead and give examples how to do it. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] destructor access to constants
Hi,
I'm wondering if it's a bug to give automatically called destructors
access to constants (PHP Version 5.0.0b1). I'd expect to be neither able
to access global variables nor constants after script termination (die()).
Ulf
$dtor = 'global $dtor variable is visible';
define('DTOR', 'DTOR constant is visible');
class dtor {
function __destruct() {
global $dtor;
printf('$dtor = %sbr DTOR = %sbr', $dtor, DTOR);
}
}
$d1 = new dtor();
unset($d1);
$d2 = new dtor();
die();
generated output:
$dtor = global $dtor variable is visible
DTOR = DTOR constant is visible
$dtor =
DTOR = DTOR constant is visible
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. It's not. Using underscores for all native PHP functions seperates them nicely from PHP based code, eg. PEAR code. php_native_func() myFunc() or even: obj-php_native_func() obj-myFunc() Ulf -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: On Wed, 03 Dec 2003 11:52:35 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: obj-php_native_func() obj-myFunc() Quick thought, does that work with overload? See Lukas post. I'm not sure if I understand this. Is there any warranty that overloaded stuff will always follow the studyCaps rule? What about a function named original_name(). Is there really a good reason why we must wrap it into OriginalName()? I'm afraid there's no one and only way. Nevertheless I preferr PHP not to use studyCaps for it's native functions/methods/whatever. It seperates the build-in functionality nicely from my code. PHP has strong roots in the C world. Most C programmers should expect that build-in labels (variables, constants, function names) use lowercase names including underscores. For those guys the absence of studyCaps is a clear indicator that they're dealing with build-in stuff. Is it really true that the entire OO-world uses study caps? C++ is a hybrid language somewhatlike PHP. As far as I know STL does not use study caps. Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). What about the existing extensions that do use studycaps (GD)? Do not change them for backward compatibility. Allow them to keep their style for the functional an the OO API (if any). Finally try to replace the entire extension with a new one. Ulf -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: On Wed, 03 Dec 2003 14:02:00 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. A OO API can add many advantages or conveniences ways that are impossible to do with with a functionnal approach. New ways, new features, new names, nothing to make Jon Doo confused :) There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). Or drop the incosistencies instead of keeping them. Ok, drop the studyCaps. What about the existing extensions that do use studycaps (GD)? Do not change them for backward compatibility. Allow them to keep their style This BC thingies in PHP5 sound always weird or silly to me (in most cases). Why in the world do we need a major release if on each case we have to take care of php4? We do have to take care. Fear the installed code base. for the functional an the OO API (if any). Finally try to replace the entire extension with a new one. Which should be the case anyway, to use the new engine features, if required. pierre -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de Pierre-Alain Joye wrote: Hello, On Wed, 03 Dec 2003 14:02:00 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: Is it really true that the entire OO-world uses study caps? C++ is a hybrid language somewhatlike PHP. As far as I know STL does not use study caps. See Morioshy post (python as well), most of the langages with OO features use studlycaps. STL..., well ;-) Well, shall we use spaces or tabs withing our code? I think most people preferr spaces... It's not really who takes the one or the other way. I could easily argue against Python? Phyton, sorry - I'm not talking anmimals. Java? I preferr tea an real computer languages like C++. In the end it boild down to a a matter of personal taste. I can arrange myself with both naming conventions. Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. A OO API can add many advantages or conveniences ways that are impossible to do with with a functionnal approach. New ways, new features, new names, nothing to make Jon Doo confused :) I'm not arguing against OO interfaces. I'm requesting consistency with existing APIs. There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). Or drop the incosistencies instead of keeping them. That's what I'm suggesting when it comes to new extension. Leave the old extension untouched for BC, try to rewrite it and convince people that you've done a good job. Such a good job as Georg (Richter) did with the mysqli extension. But: leave the old (current) extension untouched. As Hartmut said BC is a strength not a weakness. Fear the installed code base and be very careful with API changes. Be extremly careful with changes that are caused by a discussion on tastes. However this is not why I raised my voice. I'd like PHP to keep it's underscore-delimited lowercase identifiers for all kind of build-in functionality. It helps me reading and understanding my souce. All my PHP functions use studyCaps. Most build-in stuff uses underscores. This rule should be useful for beginners as well. Whenever you see a function (method) that uses underscores look it under php.net/function_name. It does not matter if it's a function or method, look it up under php.net/function_name. Whenever you spy a function (method) that uses studyCaps, try to find it's documentation on pear.php.net or... Ulf -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Derick Rethans wrote: haha, with these suckyCaps we have two different styles for core-php functions; that's worse and that's what we *should* care about. +1 And we gain a simple rule of thumb with underscores: underscores = build-in functionality = referr to php.net/function_name study = user supplied stuff = referr to pear.php.net/ or example.com/ Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
Am 11.09.2013 14:46, schrieb Johannes Schlüter: On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote: So, I think, it's time to move to a forum. I hope this is a joke. +1. A forum is a no go for me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 17.10.2014 um 11:51 schrieb Lester Caine: On 16/10/14 18:59, christopher jones wrote: Ulf stated early on in this thread re MySQL - statement and parameter are send to the server independently - the server builds the final statement string Is this ACTUALLY how it works? Since other engines prepare the statement I thought this was a mailing list about PHP. I even believed from the headline the question would be whether PHP users of MySQL would like to change an API default setting. But no, its about explaining the MySQL source code to Firebird lovers. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 17.10.2014 um 13:47 schrieb Lester Caine: users know what they are getting and where the real security holes are. Hmm, maybe, you could make this world a better one by contributing to improve http://php.net/manual/en/pdo.prepared-statements.php ? For the rest: the MySQL manual and the MySQL source code have the details. No need for speculation towards the implementation of server-side PS in MySQL, no need playing my DB vs. your DB, no need for playing the users have a right card. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Am 17.10.2014 um 15:09 schrieb Lester Caine: On 17/10/14 13:20, Ulf Wendel wrote: users know what they are getting and where the real security holes are. Hmm, maybe, you could make this world a better one by contributing to improve http://php.net/manual/en/pdo.prepared-statements.php ? PDO does not support management of SQL differences between databases. This page is a good example of where users run into problems because they have no idea if what they are copying actually works on their To me, you are making noise on the wrong list and the wrong discussion thread: file a documentation bug report. Wait, I did that for you: https://bugs.php.net/bug.php?id=68254 . Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
