Re: [PHP-DEV] RFC: ext/mysql deprecation
Rasmus Lerdorf wrote: What is true is that most people no longer build PHP at all. They just end up with whatever their provider has installed or with whatever packages they end up installing when they install the PHP app they want to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for example. It would be good if we could get the majority of the major PHP apps to commit to supporting mysqli along the same timeframe as marking this deprecated. And there is no difference here to getting PHP5.3/4 accepted as the current version of PHP? People have working systems and if the number of problems changing are too great then they don't change. Rewriting perfectly functional mysql code to use mysqli is not a trivial move, just as are the problems of re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping customers - who are most likely not even very computer literate - working while fighting the problems that changes such as removing mysql will cause them. YES people can simply switch off the checks, but again that misses the whole problem! Having switched off the checks - you have no idea what is about to blow up. I know people are getting fed up with my banging on about it - I don't have any answers - but by removing facilities that perhaps 50% of users rely on CAN only be done if there is some concerted effort to help those users who have no means of making the changes themselves? Simply saying 'We told you we were doing it' is just a kick in the teeth when you have also said 'just hide the errors and your old code will still work' - isn't it? This is not about stopping progress, it's about much better education on how that progress should be used ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Rewriting perfectly functional mysql code to use mysqli is not a trivial move, just as are the problems of re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping customers - who are most likely not even very computer literate - working while fighting the problems that changes such as removing mysql will cause them. I wonder if there have been any plans or suggestions (while dropping the old ext/mysql code) to provide some sort of seamless migration/alternatives (similar way it has been done in case of libmysql and mysqlnd)? In short - just aliasing the old mysql_* to mysqli_* functions (as most used like _query, _fetch_row/assoc have just mixed variable order)? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Christopher Jones wrote: Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi Now that IS a good start! Adding that to core documentation as well could be helpful? But in a lot of cases it is the pre-loaded 'abstraction layer' that may be the problem rather than the code for the site. 2. Mention how to turn off E_DEPRECATED warnings in the RFC? But with a strong warning that on a later version of PHP things WILL stop working altogether? More often now E_DEPRECATED is already switched off simply to get PHP5.2 code to run so no one would see them anyway! When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. I think this is part of the problem. The material from the RFC's should be used as a source to update the core documentation? Rather than another pile of notes. IS the wiki intended to be a replacement for the core documentation? I've always viewed it as a developers notepad for work that is in progress rather than documentation itself, and once completed that material moves to the core manual? In the case of removing any extension, good documentation is the key, and making this more accessible to the 'general public', who in any case will probably think 'PHP is ditching Mysql' what's going on ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi On 13 November 2012 00:29, Rasmus Lerdorf ras...@lerdorf.com wrote: That is simply not true. If you download PHP and do ./configure make install you do not get MySQL support. You have to explicitly specify that you want it. My apologies then. I actually checked a ./configure output, and saw under Configuring extensions checking for MySQL support... no I assumed it was going to try to enable it if it was available. Lots of other extensions have the wording checking whether to enable, which is why I differentiated it from those. On 13 November 2012 09:03, Lester Caine les...@lsces.co.uk wrote: YES people can simply switch off the checks, but again that misses the whole problem! Having switched off the checks - you have no idea what is about to blow up. If users wish to deliberately ignore (or worse, specifically disable) informative messages during development, that is their own problem. When ext/mysql is finally removed, nobody will be able to say they didn't have enough warning. The sooner we get this warning out there (i.e. E_DEPRECATED + message in the documentation starting with 5.5), the sooner wider community can start adjusting for it. There is no point delaying it as much as possible. As Sherif said, there has been far too much procrastination on the subject already. Lets get E_DEPRECATED in for the first RC so all of the social-focused php sites can get their rants out early, and get a few users thinking about the future of their codebases as soon as possible. Maybe even some of them will decide to contribute back and write some adoption guides and/or cheat sheets. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Leigh wrote: Hi On 13 November 2012 00:29, Rasmus Lerdorf ras...@lerdorf.com wrote: That is simply not true. If you download PHP and do ./configure make install you do not get MySQL support. You have to explicitly specify that you want it. My apologies then. I actually checked a ./configure output, and saw under Configuring extensions checking for MySQL support... no I assumed it was going to try to enable it if it was available. Lots of other extensions have the wording checking whether to enable, which is why I differentiated it from those. On 13 November 2012 09:03, Lester Caine les...@lsces.co.uk wrote: YES people can simply switch off the checks, but again that misses the whole problem! Having switched off the checks - you have no idea what is about to blow up. If users wish to deliberately ignore (or worse, specifically disable) informative messages during development, that is their own problem. When ext/mysql is finally removed, nobody will be able to say they didn't have enough warning. Leigh - the point here is that the vast majority of users know nothing about this! Their ISP has had to switch E_DEPRECATED off for all of their users simply to keep legacy sites running. 'Not our problem' is the wrong stance with so many people reliant on PHP's infrastructure. The sooner we get this warning out there (i.e. E_DEPRECATED + message in the documentation starting with 5.5), the sooner wider community can start adjusting for it. There is no point delaying it as much as possible. As Sherif said, there has been far too much procrastination on the subject already. Lets get E_DEPRECATED in for the first RC so all of the social-focused php sites can get their rants out early, and get a few users thinking about the future of their codebases as soon as possible. Maybe even some of them will decide to contribute back and write some adoption guides and/or cheat sheets. The problem will remain as to who helps the vast majority of users who are using sites that simply work for them. The problems making legacy code work with PHP5.4 are small compared with converting many millions of sites that currently use MySQL simply because that is all their ISP's provide, and the code running their site was probably installed from examples that only ever used 'mysql_' ... It's simply not practical to strip all of these old code examples from the internet, so it IS important that new examples are activly published by everybody to swamp what is now very out of date material. Many of the sites I'm currently porting from a number of ISP's have needed a lot of work to tidy them up to run on a new set-up, and there was no way their owners could ever have done that themselves! And I'm moving them to Firebird anyway so no problem with MySQl code, but I do have a couple of big sites that ARE running on mysql_ so I will need to address them at some time. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Rasmus Lerdorf in php.internals (Mon, 12 Nov 2012 16:29:35 -0800): What is true is that most people no longer build PHP at all. They just end up with whatever their provider has installed or with whatever packages they end up installing when they install the PHP app they want to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for example. Many people are now gradually moving from Drupal 6 to Drupal 7. For Drupal 7 PHP 5.3 is recommended: http://drupal.org/requirements That is not by mistake. Many Drupal 7 modules just aren't fully supporting PHP 5.4 yet. The issues are getting lower, but there still are enough issues to make me choose for PHP 5.3 om my development and production servers. It would be good if we could get the majority of the major PHP apps to commit to supporting mysqli along the same timeframe as marking this deprecated. How would you want to accomplish that? See the PHP 5.3/5.4 story. PHP 5.3 will be there for many, many years no matter how EOL the PHP community declares it. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Lester Caine wrote: Their ISP has had to switch E_DEPRECATED off for all of their users simply to keep legacy sites running. And this made me laugh ... just trying to log into a new ISP system ... ERROR: PleskFatalException Unable to connect to database: mysql_connect() How many ISP's use plesk for their user support? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Jan Ehrhardt wrote: Many people are now gradually moving from Drupal 6 to Drupal 7. For Drupal 7 PHP 5.3 is recommended: http://drupal.org/requirements (Somewhat off-topic) Conversely, WordPress is not moving to 5.3+ for a while, we still have a huge userbase on 5.2 (~66%): http://wordpress.org/about/stats/ -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
hi Rasmus, On Tue, Nov 13, 2012 at 1:29 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 11/12/2012 07:24 AM, Leigh wrote: Hi, 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. Maybe it's time to put it into full non-maintenance mode then? I believe MySQL is one of the on-by-default extensions when you compile PHP blindly (as I'm sure many do), why not make it require enabling specifically during build configuration, along with an end-of-script message that states the extension is no longer maintained (not even security fixes). That is simply not true. If you download PHP and do ./configure make install you do not get MySQL support. You have to explicitly specify that you want it. What is true is that most people no longer build PHP at all. They just end up with whatever their provider has installed or with whatever packages they end up installing when they install the PHP app they want to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for example. It would be good if we could get the majority of the major PHP apps to commit to supporting mysqli along the same timeframe as marking this deprecated. Here is the take of one of the WP core dev: My take on the RFC: Toss E_DEPRECATED in already. In our case, developers will see them, be intrigued enough to contribute. and I gather we'd have it shipped built-in in Q2 2013. refs from a twitter conversation: https://twitter.com/nacin/status/268273606386126849 https://twitter.com/nacin/status/268273185307389952 Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi Rasmus: Both Wordpress and Drupal depends on php-mysql on Ubuntu, for example. It would be good if we could get the majority of the major PHP apps to commit to supporting mysqli along the same timeframe as marking this deprecated. WordPress is moving in that direction: http://core.trac.wordpress.org/ticket/21663 --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Reinis Rozitis r...@roze.lv wrote: Rewriting perfectly functional mysql code to use mysqli is not a trivial move, just as are the problems of re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping customers - who are most likely not even very computer literate - working while fighting the problems that changes such as removing mysql will cause them. I wonder if there have been any plans or suggestions (while dropping the old ext/mysql code) to provide some sort of seamless migration/alternatives (similar way it has been done in case of libmysql and mysqlnd)? In short - just aliasing the old mysql_* to mysqli_* functions (as most used like _query, _fetch_row/assoc have just mixed variable order)? Reimplementing ext/mysql inside PHP makes no sense. The result of this would be (almost) the exact same code as we have. (ext/mysql is a exremely small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto connect and reusage of default connection) What one might try to do is changing ext/mysql to not use a resource but an mysqli object, then users might swich module by module, instead of breaking the application completely. But I fear we will introduce many bugs that way as this is a quite huge patch. An alternative approach might be to reimplement mysql_* functions using PHP userland code based on mysqli. Then users can load that lib (php.ini autoprepend_file) for compatibility and bugs can be fixed relatively simple (no C needed, no PHP release needed, ...) but again: writing such a lib is a relatively huge project. In my opinion we tell users as good as we can that ext/mysql is deprecated for some time, if we really want to get rid of it, we have to add E_DEPRECATED and then remove it.Waiting a year more won't change much, there will always people who hit it. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal deprecation process. The problem is that the deprecation process was never designed for a feature like this. Look at what was deprecated and removed so far. We deprecated register globals and magic quotes. The process worked there. But was it because of the process? Or was it because those features were already dead by that point. Think of this: when 5.3 shipped (introducing E_DEPRECATED for those features), how many current versions of open source tools relied on those features? None. Now, you could point to call-time-pass-by-reference as well. E_DEPRECATED was added in 5.3 for it. But most of the projects that used it only used it in a few minor places. The majority of usages were relatively isolated. Now, look at ext/mysql. The landscape is completely different. Major projects still rely on it in their most recent versions. Wordpress's latest trunk uses ext/mysql. And as was said here, it's not a trivial change to switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied upon. What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign to get projects like WP to switch away from it. Get the word out there as much as possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. Again, my $0.02... Anthony On Tue, Nov 13, 2012 at 10:49 AM, Johannes Schlüter johan...@schlueters.dewrote: Reinis Rozitis r...@roze.lv wrote: Rewriting perfectly functional mysql code to use mysqli is not a trivial move, just as are the problems of re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping customers - who are most likely not even very computer literate - working while fighting the problems that changes such as removing mysql will cause them. I wonder if there have been any plans or suggestions (while dropping the old ext/mysql code) to provide some sort of seamless migration/alternatives (similar way it has been done in case of libmysql and mysqlnd)? In short - just aliasing the old mysql_* to mysqli_* functions (as most used like _query, _fetch_row/assoc have just mixed variable order)? Reimplementing ext/mysql inside PHP makes no sense. The result of this would be (almost) the exact same code as we have. (ext/mysql is a exremely small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto connect and reusage of default connection) What one might try to do is changing ext/mysql to not use a resource but an mysqli object, then users might swich module by module, instead of breaking the application completely. But I fear we will introduce many bugs that way as this is a quite huge patch. An alternative approach might be to reimplement mysql_* functions using PHP userland code based on mysqli. Then users can load that lib (php.ini autoprepend_file) for compatibility and bugs can be fixed relatively simple (no C needed, no PHP release needed, ...) but again: writing such a lib is a relatively huge project. In my opinion we tell users as good as we can that ext/mysql is deprecated for some time, if we really want to get rid of it, we have to add E_DEPRECATED and then remove it.Waiting a year more won't change much, there will always people who hit it. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 13 November 2012 23:49, Johannes Schlüter johan...@schlueters.de wrote: Reinis Rozitis r...@roze.lv wrote: Rewriting perfectly functional mysql code to use mysqli is not a trivial move, just as are the problems of re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping customers - who are most likely not even very computer literate - working while fighting the problems that changes such as removing mysql will cause them. I wonder if there have been any plans or suggestions (while dropping the old ext/mysql code) to provide some sort of seamless migration/alternatives (similar way it has been done in case of libmysql and mysqlnd)? In short - just aliasing the old mysql_* to mysqli_* functions (as most used like _query, _fetch_row/assoc have just mixed variable order)? Reimplementing ext/mysql inside PHP makes no sense. The result of this would be (almost) the exact same code as we have. (ext/mysql is a exremely small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto connect and reusage of default connection) What one might try to do is changing ext/mysql to not use a resource but an mysqli object, then users might swich module by module, instead of breaking the application completely. But I fear we will introduce many bugs that way as this is a quite huge patch. An alternative approach might be to reimplement mysql_* functions using PHP userland code based on mysqli. Then users can load that lib (php.ini autoprepend_file) for compatibility and bugs can be fixed relatively simple (no C needed, no PHP release needed, ...) but again: writing such a lib is a relatively huge project. In my opinion we tell users as good as we can that ext/mysql is deprecated for some time, if we really want to get rid of it, we have to add E_DEPRECATED and then remove it.Waiting a year more won't change much, there will always people who hit it. +1 on all of that. I was trying to crystallise my thoughts on the way home, and you've done it for me. Thanks, Johannes. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 14 November 2012 00:07, Anthony Ferrara ircmax...@gmail.com wrote: There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal deprecation process. The problem is that the deprecation process was never designed for a feature like this. Serious question: what was it designed for, then? This (along with magic quotes, and register globals) was always what I had in the back of my mind when it was being discussed. snip Now, look at ext/mysql. The landscape is completely different. Major projects still rely on it in their most recent versions. Wordpress's latest trunk uses ext/mysql. And as was said here, it's not a trivial change to switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied upon. Last time I checked, WordPress's trunk also emulated magic quotes. Old code is old. With all due respect to the WP developers, they've made a very deliberate choice to maintain extreme backward compatibility because their plugin ecosystem demands it. Ultimately, they'll presumably emulate mysql_* in userland if it's that important to them, just as they are with magic quotes. I don't think we should let that stop us from removing dead code, or replacing APIs that promote antipatterns. What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign to get projects like WP to switch away from it. Get the word out there as much as possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. It's already deprecated in the documentation, really — I doubt adding the actual word deprecated will make a difference. If we're going to drag this out, I'd rather spend an extra year with PHP actually generating warnings, as I said upthread. Adam -- 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 17:07, schrieb Anthony Ferrara: What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign to get projects like WP to switch away from it. Get the word out there as much as possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. This will just postpone people acting by one or two additional years. E_DEPRECATED urges to act by spamming logs (at least those who do not silence it. It doesn't hurt the rest). By PHP 6 this thing should be gone for good. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
2012/11/13 Anthony Ferrara ircmax...@gmail.com There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal deprecation process. The problem is that the deprecation process was never designed for a feature like this. Look at what was deprecated and removed so far. We deprecated register globals and magic quotes. The process worked there. But was it because of the process? Or was it because those features were already dead by that point. Think of this: when 5.3 shipped (introducing E_DEPRECATED for those features), how many current versions of open source tools relied on those features? None. Now, you could point to call-time-pass-by-reference as well. E_DEPRECATED was added in 5.3 for it. But most of the projects that used it only used it in a few minor places. The majority of usages were relatively isolated. Now, look at ext/mysql. The landscape is completely different. Major projects still rely on it in their most recent versions. Wordpress's latest trunk uses ext/mysql. And as was said here, it's not a trivial change to switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied upon. What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign to get projects like WP to switch away from it. Get the word out there as much as possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. Again, my $0.02... Anthony It took me like 10 minutes of Search Replace in my IDE to make a switch to mysqli and a few more hours to validate that everything is ok and catch places where search replace failed. The amount of work is overestimated, especially if you have a regexp capable search replace. Not being able to migrate to mysqli in a few days is a sign of project messed up so badly, that just upgrading your PHP should break it every time, and you are probably better off rewriting the whole thing. Or just freeze the PHP version you are using and let it live until you are able to rewrite it. Unfortunately people need a kick in the nuts to start to act. And that old project argument is exactly from the people that need that kick in the first place. I don't even wana start about using a VPS/virtualization and compiling the damn thing --with-mysql and being happy that you don't have to do anything to keep it running.
[PHP-DEV] HEADS UP: PHP-5.5 branched.
Hi Internals, with the first alpha going to be tagged today and officially released on Thursday, I went ahead and created the 5.5 branch. Merging should be still straight forward, but it's going to be 5.3 - 5.4 - 5.5 - master. I know this is a mess, but I think we'll have to live with that for a while. Therefore bigger BC breaks can be applied to master as well. Following the versioning scheme of 5.4.x version, I versioned master as 5.5.99 until we decide if it's going to be a 5.6.0 or a 6.0.0. Again, if someone wnats to come up with a better plan to have a branch open for bigger BC breaks and creating less branches, let us know. For reference: PHP-5.5 is still open for new features. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Tue, Nov 13, 2012 at 8:28 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: It took me like 10 minutes of Search Replace in my IDE to make a switch to mysqli and a few more hours to validate that everything is ok and catch places where search replace failed. The amount of work is overestimated, especially if you have a regexp capable search replace. 10 minutes x 50 billion (http://www.statisticbrain.com/total-number-of-pages-indexed-by-google/ ) is not a trivial number. Heck, assume even only 10% of the web pages on the internet use mysql_* calls, and you're still talking 50 billion minutes, or about 95 thousand years. At 1%, it's only 9 thousand years, possibly greater than the entire written and recorded history of the human race. Considering there are a huge quantity of PHP end users (Drupal, Joomla, Wordpress, Magento, etc.) who don't even know what 'regexp' means, and would take a lot more time than ten minutes just trying to understand why my website is broken, can you fix it? yeah. On the less pessimistic side, since I work as a PHP site author/maintainer for a living, a pool of 9,000 years of work would suit me just fine. Even 900 years would equate to a huge jobs program for my field. -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 13 November 2012 16:07, Anthony Ferrara ircmax...@gmail.com wrote: What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign to get projects like WP to switch away from it. Get the word out there as much as possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. A very brief interjection from the documentation team's side of the fence (though I can't speak for everyone). Extensions, functions, etc. marked as deprecated in the documentation reflect the reality in the code. If a function is deprecated in php-src, then we document it as such in the manual. Since ext/mysql is not yet deprecated in the source, we cannot officially deprecate it in the docs with the usual this function is deprecated, blah, blah messages. This is why we have adopted the soft-deprecation boxes in the manual especially for ext/mysql, to step forward with that PR campaign (which has been going on for years upon years) until such a time as the extension is actually marked as deprecated in php-src. Long story short, the manual reflects the source. Put the deprecation into a release and we can document the extension as such. Hold back on the deprecation in the source and we can't stick a paragraph in the docs saying this is deprecated, rather we can only continue to say that its use is discouraged. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
hi, On Tue, Nov 13, 2012 at 7:29 PM, Ronald Chmara rona...@gmail.com wrote: On Tue, Nov 13, 2012 at 8:28 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: It took me like 10 minutes of Search Replace in my IDE to make a switch to mysqli and a few more hours to validate that everything is ok and catch places where search replace failed. The amount of work is overestimated, especially if you have a regexp capable search replace. 10 minutes x 50 billion (http://www.statisticbrain.com/total-number-of-pages-indexed-by-google/ ) is not a trivial number. Heck, assume even only 10% of the web pages on the internet use mysql_* calls, and you're still talking 50 billion minutes, or about 95 thousand years. At 1%, it's only 9 thousand years, possibly greater than the entire written and recorded history of the human race. Considering there are a huge quantity of PHP end users (Drupal, Joomla, Wordpress, Magento, etc.) who don't even know what 'regexp' means, and would take a lot more time than ten minutes just trying to understand why my website is broken, can you fix it? yeah. On the less pessimistic side, since I work as a PHP site author/maintainer for a living, a pool of 9,000 years of work would suit me just fine. Even 900 years would equate to a huge jobs program for my field. Can we stop about arguing about the removal? It is not happening and won't until 6+. We are talking about adding a E_DEPECRATED notice, nothing else. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: PHP-5.5 branched.
On Nov 13, 2012, at 18:44, David Soria Parra d...@php.net wrote: Following the versioning scheme of 5.4.x version, I versioned master as 5.5.99 until we decide if it's going to be a 5.6.0 or a 6.0.0 Repeating what was said for 5.4.99: I don't think this is good. This makes version comparison harder. Use 5.6.0-dev. We can increase to 6.0 or 10.0 as needed. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 13, 2012, at 18:07, Anthony Ferrara ircmax...@gmail.com wrote: There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal deprecation process. The problem is that the deprecation process was never designed for a feature like this. I don't agree. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 13, 2012, at 18:28, Arvids Godjuks arvids.godj...@gmail.com wrote: It took me like 10 minutes of Search Replace in my IDE to make a switch to mysqli and a few more hours to validate that everything is ok and catch places where search replace failed. The amount of work is overestimated, especially if you have a regexp capable search replace. That's not enough in many cases: A key property of ext/MySQL is that you have this default connection so users don't have to pass a connection handle. Adding that in a sane way can quickly become non-trivial. A help there exists, though: Chris posted the link to the oracle wiki which has a link to some script we in the MySQL company wrote (actually that was done before I joined) which tries to convert ext/mysql based applications to mysqli whole trying to catch more edge cases. Not being able to migrate to mysqli in a few days is a sign of project messed up so badly, that just upgrading your PHP should break it every time, and you are probably better off rewriting the whole thing. Or just freeze the PHP version you are using and let it live until you are able to rewrite it. Actually PHP has a quite good BC story. Yes, sometimes we break thing (on purpose or accident) but in 90% of the cases easy workaround a exist (I.e. emulating register_globals is quite easy). So users can migrate their crappy code from version to version and be happy. Swapping out database access in a mixture of PHP, HTML and SQL is way harder. Unfortunately people need a kick in the nuts to start to act. And that old project argument is exactly from the people that need that kick in the first place. I agree, docs and these things aren't enough. E_DEPRECATED is our tool for this. I don't even wana start about using a VPS/virtualization and compiling the damn thing --with-mysql and being happy that you don't have to do anything to keep it running. Well, you still need --with-mysqli (or --with-pdo-mysql) which is even more to type ;) johannes -- Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: PHP-5.5 branched.
On Tue, 13 Nov 2012, Johannes Schlüter wrote: On Nov 13, 2012, at 18:44, David Soria Parra d...@php.net wrote: Following the versioning scheme of 5.4.x version, I versioned master as 5.5.99 until we decide if it's going to be a 5.6.0 or a 6.0.0 Repeating what was said for 5.4.99: I don't think this is good. This makes version comparison harder. Use 5.6.0-dev. We can increase to 6.0 or 10.0 as needed. +1, and also bump PHP_VERSION_ID to 50600 for that one please! cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: PHP-5.5 branched.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Makes sense, I'll bumped the version to 5.6.0-dev On Tue 13 Nov 2012 08:23:31 PM CET, Derick Rethans wrote: On Tue, 13 Nov 2012, Johannes Schlüter wrote: On Nov 13, 2012, at 18:44, David Soria Parra d...@php.net wrote: Following the versioning scheme of 5.4.x version, I versioned master as 5.5.99 until we decide if it's going to be a 5.6.0 or a 6.0.0 Repeating what was said for 5.4.99: I don't think this is good. This makes version comparison harder. Use 5.6.0-dev. We can increase to 6.0 or 10.0 as needed. +1, and also bump PHP_VERSION_ID to 50600 for that one please! cheers, Derick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQoqLhAAoJEKSanlo0ToXKAgEP/iGi/oPhO4GpcjYSSu+Dactj CE4eA4jJdT2J8cGJo8iULgrXgRAS83nFYfIXgPNOTOwbdrd467YxJjpLGtToJWsO oYofZs667MVZepaU0RhIXIYJgchWgrd17Su41Gkc+trff+LeaCfBHFlKTsb0w4vt s0SMDuryRnTBSJzjcdiURP3kB+oBXHVo/kSt4oTBpTcEsLVLThXGtTCtNa1A5VSV 4oJw0K7y5QboTj8oqKpZdIocYkyI08ybGeRCG2BK7hIVCFcQmdAlZntPCNbYn27W j+MEGg8XzZxCnld964rOo4IKcBPsATyrK8JeQI9QNf5eYUR/AD+uYDJpce+OQ/+2 mJ53AYNnexL+IXvl/8lFR21nbzS/OQKE7+yrui4lzXIJrm1/gKygqgVyOttwds/S gVMDM17/8uC7oVqtOT38enue79EGNmRsfvAydTm4+cVx3Y9RyAnIqhbc9Aq6zHif dkzxv4aDowoaVwh9QidiuFZDiGal1nRozrAVdQD4nZwTHgpo5bq1u5oX4uZi/N16 Gduy8hwBqKiVbbmpUUj++rm25LqpAK+AYYWW7Am5cbRegEwOT2D+1vEAxTJl5rkb bysJ8pc1NwiPFdhaPVhV2mq5uNyEqyTNvj2nVJCJFV6As3g2K29phzPKuTyKNq9D NA41oe0MAA7LvsKCigh7 =KuW9 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Tue, Nov 13, 2012 at 11:17 AM, Adam Harvey ahar...@php.net wrote: On 14 November 2012 00:07, Anthony Ferrara ircmax...@gmail.com wrote: There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal deprecation process. The problem is that the deprecation process was never designed for a feature like this. Serious question: what was it designed for, then? This (along with magic quotes, and register globals) was always what I had in the back of my mind when it was being discussed. snip Now, look at ext/mysql. The landscape is completely different. Major projects still rely on it in their most recent versions. Wordpress's latest trunk uses ext/mysql. And as was said here, it's not a trivial change to switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied upon. Last time I checked, WordPress's trunk also emulated magic quotes. Old code is old. With all due respect to the WP developers, they've made a very deliberate choice to maintain extreme backward compatibility because their plugin ecosystem demands it. Ultimately, they'll presumably emulate mysql_* in userland if it's that important to them, just as they are with magic quotes. I don't think we should let that stop us from removing dead code, or replacing APIs that promote antipatterns. What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign to get projects like WP to switch away from it. Get the word out there as much as possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. It's already deprecated in the documentation, really — I doubt adding the actual word deprecated will make a difference. If we're going to drag this out, I'd rather spend an extra year with PHP actually generating warnings, as I said upthread. I'm with you 100% on this. Wasting *yet another few years* on telling people... hey, soon we will actually begin to discussing, thinking, of taking action about maybe deprecating the functions officially in an official manner by which we mean actually throwing the warnings this time, but for real now not just in the documentation... Seriously, we're not joking this time... Please, this has been dragged out long enough. Give them the warning, let the next few years push those with dependency issues into forcing support on their upstreams. Software must be tolerant of failure and capable of reiteration if it is to strive. I truly think this should we or should we throw E_DEPRECATED back-and-forth business is rather silly. It's not like E_DEPRECATED is going to cause every PHP code base on earth to suddenly and spontaneously combust over night. We are talking about a version of PHP that will probably take half of these projects the next 3 years to upgrade to (in terms of the majority of their user bases). By then they're not even using a version of PHP where the extension has been removed yet. Come on, I mean the wordpress guys are showing statistics that a 3rd of their entire user base is still using PHP 5.2 for crying out loud. Let's not over-dramatize this thing. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/13/2012 01:40 AM, Lester Caine wrote: Christopher Jones wrote: When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. I think this is part of the problem. The material from the RFC's should be used as a source to update the core documentation? Rather than another pile of notes. It's not a problem. We point them to the wiki so they can see the rationale behind the change. This potentially reduces user frustration. Our documentation should not have that rationale. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi Anthony: On Tue, Nov 13, 2012 at 11:07:53AM -0500, Anthony Ferrara wrote: Wordpress's latest trunk uses ext/mysql. WordPress uses a wpdb object. Switching out the class to a mysqli based one is pretty simple and a patch exists. I have a feeling it'll make it into 3.6. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
I see several problems with deprecating ext/mysql: - The extension is not broken. The problem is the bad usage. It can be used safely, and good developers have been doing so for ages, by creating php wrappers. In magic quotes, the work has been the opposite. The developers had been detecting the feature in php and *disabling* it. - How many hosts/ISPs have mysqli installed? I don't have actual numbers, but it used to be much less common than ext/mysql, which means that unless they those customers won't be able to run the applications forced to migrate to mysqli. Yes, the customers should complain and get the extension enabled, but what will happen instead is that they will use outdated version X of WordPress, since that one works. So the problem really moves onto the CMS providers, do they support new php versions and drop customers in shared hosting, do they delay supporting the new php versions, or do they reimplement mysql_* in php? - A magic porting script has been mentioned on this thread. It is not on the docs, so it is really as if it didn't exist for the 99% of the population. Moreover, there is even a FAQ stating that there are no migration scripts right now: http://php.net/manual/en/faq.databases.php#faq.databases.mysql.deprecated It should be linked from every mysql page. - If you are sure your ext/mysql usage is safe, it is not possible to disable the warning for this functions but keep the other E_DEPRECATED. - I'm quite sure that there will be a number of problems where the replacements have issues, but they are unlikely to be fixed if not forced. For instance, I remember a php script using mysql that from reading the code, it shouldn't be working but it somehow did. Completely unmaintained, of course. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 14.11.2012 00:23, schrieb Ángel González: So the problem really moves onto the CMS providers, do they support new php versions and drop customers in shared hosting, do they delay supporting the new php versions, or do they reimplement mysql_* in php? We are talking about ~1.5 years until ext/mysql is really removed. Don't you think all big project will be able to remove it during that timerange? And no big hosting provider will roll out that new version on day 1, so you will not see many hosters running PHP 5.6 (where ext/mysql is removed) in the next 2 years. Enough time to get rid of the old mysql_* things. Deprecated warnings do not hurt anybody, in production environments they are not visible, so where is the problem? Nothing will break with 5.5 Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi! But with a strong warning that on a later version of PHP things WILL stop working altogether? More often now E_DEPRECATED is already switched off simply Why again we must breaking people's working code? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hi! 2. Mention how to turn off E_DEPRECATED warnings in the RFC? Done and done. I've added a (short) workarounds section towards the bottom, which can be moved up later if the RFC is accepted. Please note currently PHP has no mechanism of turning off any warnings or errors. The best you can do is to cause them not be printed. However, any tool that intercepts error messages still sees them, they still consume resources when produced, still may break unit tests if you're not aware of them and they convert errors to failures like PHPUnit does, still will break any code that sets it's won error reporting if it doesn't remember to disable deprecated messages, etc. So adding warnings hurts performance and may hurt functionality even if you don't see them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
