# [VOTE] ext/mysql deprecation in 5.5 - Thread: https://externals.io/message/64065 - Original archive: https://news-web.php.net/php.internals/64065 - Started by Adam Harvey on 2012-11-28T06:03:20+00:00 - Messages: 34 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/64065.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64065 — Adam Harvey — 2012-11-28T06:03:20+00:00 URL: https://externals.io/message/64065#64065 All, I've moved the ext/mysql deprecation RFC into the voting phase. You can vote at https://wiki.php.net/rfc/mysql_deprecation — note that, as discussed last week, there are two questions: the first being a simple yes/no question (which will determine whether the RFC is accepted or rejected), and the second to clarify what the preferred course of action will be if the RFC is declined. Please vote on both, unless you particularly wish to abstain from one of the questions. I've also updated the RFC slightly, but not in a way that changes what's actually proposed: Ulf noted that he wasn't comfortable with having the Oracle Wiki link there for converting to MySQLi, so I've replaced that link with another, more recent tutorial (albeit PDO only) and added a link to Ulf's recent blog post about the benefits of mysqli and PDO over ext/mysql. This is mostly useful for documentation purposes, since I think there's general agreement that we should have more resources covering upgrading to newer extensions regardless of the outcome of this RFC. At this stage, I intend to close the vote in a week's time: so Wednesday, December 5. Thanks, Adam, who knows he's a little late with this, but being sick sucks. Sorry. --- ## #64066 — Adam Harvey — 2012-11-28T06:14:39+00:00 URL: https://externals.io/message/64065#64066 · In reply to: #64065 OK, so the first e-mail was the official announcement of voting being open. I'd now like to quickly lay out why I voted yes, and why I think it's the right way forward. Feel free to hit next if your mind is already made up. :) Ulf produced a blackly entertaining timeline of MySQL support in PHP in one of the earlier RFC threads[0]. We've had better options than ext/mysql available in mainline, stable releases since 2004, yet it's taken a long time for there to be a serious push to encourage users to use the newer extensions. There are both a carrot and a stick here. The carrot is well laid out by Ulf in his blog post[1] — the newer extensions are more featureful, faster, and in the case of PDO particularly, easier to use (and harder to misuse). The stick is that we have this faintly ridiculous situation where we have four extensions in php-src for accessing one DBMS, one of which (ext/mysql) is barely maintained and has an API that encourages poor programming practice. Deprecating ext/mysql in PHP 5.5 doesn't mean it's going away immediately. It doesn't even mean it's going away next year: there's no reason at all we can't keep ext/mysql deprecated for more than one release branch. In fact, that would be my preference. As others have said: ext/mysql is a hugely used, popular extension. We can't rip it out overnight, and nor should we. Deprecation is a strong signal. It's a signal that it's time to update tutorials. It's a signal to schedule upgrades for code when new versions are written to use more modern APIs. It's a signal to those of us who speak at conferences, and help people in various fora and various ways that we should redouble our efforts to communicate the benefits of MySQLi and/or PDO. Most of all, it's a signal that we're serious about improving PHP and encouraging our users to improve their own code with us. Thanks for reading. If you got this far, I'll buy you the beer or non-alcoholic substitute of your choice at any conference I'm at next year. (Which, since I'm moving to Vancouver in the new year, may actually be a few.) Adam [0] http://news.php.net/php.internals/63982 [1] http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/ --- ## #64067 — Lester Caine — 2012-11-28T09:29:54+00:00 URL: https://externals.io/message/64065#64067 · In reply to: #64066 Adam Harvey wrote: > Deprecation is a strong signal. It's a signal that it's time to update > tutorials. It's a signal to schedule upgrades for code when new > versions are written to use more modern APIs. It's a signal to those > of us who speak at conferences, and help people in various fora and > various ways that we should redouble our efforts to communicate the > benefits of MySQLi and/or PDO. Since I don't have karma to vote on line I need to raise my objections here. There is no 'objection' to deprecating the extension, but adding `E_DEPRECATED` to the code is problematic since that should NOT be present in a PECL version of the code? Adding it in one location and not the other does not make sense. ALL that is needed is that the 'extension' is more difficult to access than the preferred alternatives. When MySQL was dropped as 'automatically enabled' and people kept asking 'Where is it?' people accepted the reasoning. Doing the same thing now warning at the loading stage makes this much more practical, since having to disable `E_DEPRECATED` because of running legacy code and then loosing also the IMPORTANT deprecated warnings is just wrong! I'd almost make a case for moving the currently clean code to PECL now so we CAN load a clean version of mysql if we need to do that. It's bundling it with other deprecated code that is my problem :( Personally I'm only running MySQL to support legacy code, and if this goes ahead then it's another reason to stop upgrading from PHP5.4 ... -- 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 --- ## #64068 — Alexey Zakhlestin — 2012-11-28T09:55:19+00:00 URL: https://externals.io/message/64065#64068 · In reply to: #64067 I voted "no", "(b)" We should mention deprecation in manual as hard as possible, we should mention it in ext/mysql/config.m4 and any other place we can reach. Then, at some point (I'm fine with 5.6, but 6.0 would do also), we should just move it to PECL, without using `E_DEPRECATED` -- Alexey Zakhlestin, http://github.com/indeyets --- ## #64069 — Pierre Joye — 2012-11-28T10:08:54+00:00 URL: https://externals.io/message/64065#64069 · In reply to: #64068 hi, > I voted "no", "(b)" > We should mention deprecation in manual as hard as possible, we should > mention it in ext/mysql/config.m4 and any other place we can reach. > Then, at some point (I'm fine with 5.6, but 6.0 would do also), we > should just move it to PECL, without using `E_DEPRECATED` That's exactly why we should use `E_DEPRECATED` now and not in 5.x+1. Also no way to kill it in 5.x, that would be worst than anything else. That being said, let not start this thread, every argument has been mentioned many times already. Let vote. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #64070 — Philip Olson — 2012-11-28T10:30:48+00:00 URL: https://externals.io/message/64065#64070 · In reply to: #64069 > hi, > > > > […] > > That's exactly why we should use `E_DEPRECATED` now and not in 5.x+1. > Also no way to kill it in 5.x, that would be worst than anything else. The idea of adding `E_DEPRECATED` now, and then removing it in PECL, is not an opinion held by everyone. > That being said, let not start this thread, every argument has been > mentioned many times already. Let vote. The idea of moving it to PECL is not represented in the vote. But it's something to consider as it's a real possibility. It could both symbolize that we are serious about not using ext/mysql, and considering most Linux distros would simply switch to offering the PECL version, it'd probably not break much. Worth thinking about, at least. I'm not yet certain what we should do but this PECL topic is intriguing. Hopefully a few others will weigh in with their related thoughts. Regards, Philip --- ## #64074 — Nikita Popov — 2012-11-28T14:22:02+00:00 URL: https://externals.io/message/64065#64074 · In reply to: #64070 > The idea of moving it to PECL is not represented in the vote. But > it's something to consider as it's a real possibility. It could > both symbolize that we are serious about not using ext/mysql, and > considering most Linux distros would simply switch to offering the > PECL version, it'd probably not break much. Worth thinking about, > at least. > Yes, in my eyes it is really pointless to start throwing deprecation warnings and then move it to PECL. Please add the option of a direct PECL-move to the second vote. Nikita --- ## #64075 — Patrick ALLAERT — 2012-11-28T14:50:47+00:00 URL: https://externals.io/message/64065#64075 · In reply to: #64067 2012/11/28 Lester Caine : > There is no 'objection' to deprecating the extension, but adding > `E_DEPRECATED` to the code is problematic since that should NOT be present in > a PECL version of the code? Sorry, but removing the `E_DEPRECATED` notice when moved to PECL is not part of the proposed RFC and should certainly not happen. If ext/mysql is deprecated, it can perfectly live in PECL while remaining deprecated. There ARE (supported) replacements for ext/mysql and even if someone really one to use it, it should still be considered deprecated regardless of the repository holding the code. > Adding it in one location and not the other does > not make sense. Absolutely! There is no reason to remove that kind of notice in the future. -- Patrick --- ## #64077 — Lester Caine — 2012-11-28T16:30:44+00:00 URL: https://externals.io/message/64065#64077 · In reply to: #64075 Patrick ALLAERT wrote: > 2012/11/28 Lester Caine: > > […] > Sorry, but removing the `E_DEPRECATED` notice when moved to PECL is not > part of the proposed RFC and should certainly not happen. > If ext/mysql is deprecated, it can perfectly live in PECL while > remaining deprecated. There ARE (supported) replacements for ext/mysql > and even if someone really one to use it, it should still be > considered deprecated regardless of the repository holding the code. > > […] > Absolutely! There is no reason to remove that kind of notice in the future. Then perhaps a few more people will start complaining as well then. There is NO reason to have deprecated messages on legacy packages in PECL no other older packages have them? So why pick out this one? This NOT the way to handle retiring well used legacy extensions and it just gets in the way of using `E_DEPRECATED` when it IS needed! At the very minimum we should be able to ignore warnings when they are well understood without having to hide everything else as well :( -- 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 --- ## #64078 — Reinis Rozitis — 2012-11-28T16:36:11+00:00 URL: https://externals.io/message/64065#64078 · In reply to: #64075 > From: Patrick ALLAERT > > Sorry, but removing the `E_DEPRECATED` notice when moved to PECL is not part > of the proposed RFC and should certainly not happen. I don't get what is the reason behind it? Yes, the extension is old but it still works perfectly fine and even outperforms the newer mysqli/pdo in some cases and noone will rewrite the legacy apps - so why is there such a hate (I must say) for ISPs and platform providers? If you insist on throwing errors in external pecl extension for me as a server farm administrator it won't leave any choice but to edit the extension code / build custom distro package before putting it on production. rr --- ## #64079 — Anthony Ferrara — 2012-11-28T16:36:57+00:00 URL: https://externals.io/message/64065#64079 · In reply to: #64065 Adam, Thanks for opening voting. However, I'd like to ask you to do something else here. Can you please update the RFC to reflect the discussions that happened on list? Not everything that was talked about, but the major discussion points at least. That way it's there for future reference, and people who didn't read the entire discussion thread can get a summary before they vote. As it sits now, it doesn't really present all sides of the issue well... Thanks Anthony > All, > > I've moved the ext/mysql deprecation RFC into the voting phase. You > can vote at https://wiki.php.net/rfc/mysql_deprecation — note that, as > discussed last week, there are two questions: the first being a simple > yes/no question (which will determine whether the RFC is accepted or > rejected), and the second to clarify what the preferred course of > action will be if the RFC is declined. Please vote on both, unless you > particularly wish to abstain from one of the questions. > > I've also updated the RFC slightly, but not in a way that changes > what's actually proposed: Ulf noted that he wasn't comfortable with > having the Oracle Wiki link there for converting to MySQLi, so I've > replaced that link with another, more recent tutorial (albeit PDO > only) and added a link to Ulf's recent blog post about the benefits of > mysqli and PDO over ext/mysql. This is mostly useful for documentation > purposes, since I think there's general agreement that we should have > more resources covering upgrading to newer extensions regardless of > the outcome of this RFC. > > At this stage, I intend to close the vote in a week's time: so > Wednesday, December 5. > > Thanks, > > Adam, who knows he's a little late with this, but being sick sucks. Sorry. --- ## #64080 — Anthony Ferrara — 2012-11-28T16:43:51+00:00 URL: https://externals.io/message/64065#64080 · In reply to: #64075 Patrick, Sorry, but removing the `E_DEPRECATED` notice when moved to PECL is not > part of the proposed RFC and should certainly not happen. > The proposal doesn't actually propose anything about a move to PECL. It's listed in the "possible future actions" section exactly once. But the RFC doesn't take a stand on it in either direction. So I'm not sure that you can make that argument. > Adding it in one location and not the other does > > […] > > Absolutely! There is no reason to remove that kind of notice in the future. > That's your opinion. Please realize it as such and that other viewpoints also exist. For example, I have the viewpoint that deprecation applies to the LANGUAGE. The inclusion of the extension in the language is what's being deprecated. Even after it's pulled, someone else can maintain it. We can say that you should avoid it, but there's nothing stoping someone else from continuing maintenance of it as a fork. And adding in the other missing functionality (possibly breaking BC, possibly not, whatever). Therefore, in my viewpoint, the deprecation notices only apply to the inclusion of the extension in the core language distribution. Not to the extension itself. I'm not saying that either one of us is right or wrong, just that there are other opinions. To keep this discussion productive, please refrain from using absolutes like that... Thanks Anthony --- ## #64081 — keisial@gmail.com — 2012-11-28T18:09:39+00:00 URL: https://externals.io/message/64065#64081 · In reply to: #64070 I see it as simple to show `E_DEPRECATED` but not when installed from PECL. 1) Add a int mysql_extension_triggers_deprecated_warning = 1; And use it as a conditional for triggering the warning. 2) Copy the extension code to PECL 3) Add these changes in PECL - If the mysql functions are not already registered, register them with the bundled code. - Set mysql_extension_triggers_deprecated_warning = 0; 4) That's it. --- ## #64083 — Kris Craig — 2012-11-28T20:33:55+00:00 URL: https://externals.io/message/64065#64083 · In reply to: #64080 On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara wrote: > Patrick, > > > Sorry, but removing the `E_DEPRECATED` notice when moved to PECL is not > > […] > > The proposal doesn't actually propose anything about a move to PECL. It's > listed in the "possible future actions" section exactly once. But the RFC > doesn't take a stand on it in either direction. So I'm not sure that you > can make that argument. > > > […] > future. > > […] > > That's your opinion. Please realize it as such and that other viewpoints > also exist. > > For example, I have the viewpoint that deprecation applies to the LANGUAGE. > The inclusion of the extension in the language is what's being deprecated. > Even after it's pulled, someone else can maintain it. We can say that you > should avoid it, but there's nothing stoping someone else from continuing > maintenance of it as a fork. And adding in the other missing functionality > (possibly breaking BC, possibly not, whatever). > > Therefore, in my viewpoint, the deprecation notices only apply to the > inclusion of the extension in the core language distribution. Not to the > extension itself. > > I'm not saying that either one of us is right or wrong, just that there are > other opinions. To keep this discussion productive, please refrain from > using absolutes like that... > > Thanks > > Anthony > I think we're over-complicating this a bit. The whole point of `E_DEPRECATED` is to get people to stop using an obsolete feature before it's removed (or moved to PECL or whatever; neither of which is in the scope of this RFC anyway). Documentation and whatnot can only accomplish so much. We also know that `E_DEPRECATED` works when other approaches do not. I would point you all to the famous example of Drupal 7, which would break completely due to a flurry of `E_DEPRECATED` warnings (if display_errors was set to on) being triggered as of 5.3 due to their continued use of magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some time later, the code was fixed so that it no longer used those out-dated functions. That's why I voted yes. --Kris --- ## #64086 — Kalle Sommer Nielsen — 2012-11-28T23:30:05+00:00 URL: https://externals.io/message/64065#64086 · In reply to: #64065 2012/11/28 Adam Harvey : > At this stage, I intend to close the vote in a week's time: so > Wednesday, December 5. +1 for deprecation in 5.5 -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #64087 — Martin Nicholls — 2012-11-29T01:33:28+00:00 URL: https://externals.io/message/64065#64087 > - Users will get warnings on upgrading - it can not be hidden by > hosters/distros etc. Think you might be wildly underestimating the ability of both distros and stuff like cPanel to patch the extension. Then again - I think everybody might be. --- ## #64089 — David Muir — 2012-11-29T01:55:35+00:00 URL: https://externals.io/message/64065#64089 · In reply to: #64083 > On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara wrote: > > > […] > I think we're over-complicating this a bit. The whole point of > `E_DEPRECATED` is to get people to stop using an obsolete feature before it's > removed (or moved to PECL or whatever; neither of which is in the scope of > this RFC anyway). Documentation and whatnot can only accomplish so much. > > We also know that `E_DEPRECATED` works when other approaches do not. I would > point you all to the famous example of Drupal 7, which would break > completely due to a flurry of `E_DEPRECATED` warnings (if display_errors was > set to on) being triggered as of 5.3 due to their continued use of > magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some > time later, the code was fixed so that it no longer used those out-dated > functions. > > That's why I voted yes. > > --Kris > Kris, There was no "ext/magic_quotes" that was retired to PECL. You're comparing apples with oranges. David --- ## #64090 — Kris Craig — 2012-11-29T03:17:00+00:00 URL: https://externals.io/message/64065#64090 · In reply to: #64089 > Kris, > > There was no "ext/magic_quotes" that was retired to PECL. You're comparing > apples with oranges. > > David > > I disagree. Whether we're deprecating an extension or a subset of functions, the practical impact is pretty much the same. As for moving it to PECL, why are we even discussing that here? It's completely outside the scope of this RFC. I imagine moving it to PECL would make the most sense when the time comes, but we shouldn't get ahead of ourselves. We should deprecate it first, then when the time comes (i.e. 6.0) we can figure out where to dump its carcas. Either way, our common goal here is to get people to stop using ext/mysql now so that we can trash it when the time comes. And as far as that goes, I think that what happened with magic_quotes and Drupal is a perfect example of how deprecation can effectively push devs to act when docs and "get the word out" campaigns aren't enough. --Kris --- ## #64091 — Anthony Ferrara — 2012-11-29T04:28:25+00:00 URL: https://externals.io/message/64065#64091 · In reply to: #64090 Kris, I disagree. Whether we're deprecating an extension or a subset of > functions, the practical impact is pretty much the same. As for moving it > to PECL, why are we even discussing that here? It's completely outside the > scope of this RFC. I imagine moving it to PECL would make the most sense > when the time comes, but we shouldn't get ahead of ourselves. We should > deprecate it first, then when the time comes (i.e. 6.0) we can figure out > where to dump its carcas. > Actually, it is very much within the scope of this discussion. Case in point, take a look at 5.3.0. The following extensions were moved to PECL: - ext/dbase - ext/fbsql - ext/fdf - ext/ncurses - ext/mhash (BC layer is now entirely within ext/hash) - ext/ming - ext/msql - ext/sybase Now you could make the argument that they weren't as used as ext/mysql. But they were removed from core without raising `E_DEPRECATED` first. So there definitely is precedent to remove without deprecating first. So it's completely within the realm of discussion here. Either way, our common goal here is to get people to stop using ext/mysql > now so that we can trash it when the time comes. And as far as that goes, > I think that what happened with magic_quotes and Drupal is a perfect > example of how deprecation can effectively push devs to act when docs and > "get the word out" campaigns aren't enough. > The problem with this statement is that you're indicating something that didn't happen. "get the word out" campaigns have not happened on an official level for ext/mysql. The wording in the docs is light at best. There has been very little effort from the side of the project to say "get off it now". And that's what some of us have against this concept of raising `E_DEPRECATED` in 5.5 (or possibly ever)... Anthony --- ## #64092 — Adam Harvey — 2012-11-29T04:49:18+00:00 URL: https://externals.io/message/64065#64092 · In reply to: #64079 > However, I'd like to ask you to do something else here. Can you please > update the RFC to reflect the discussions that happened on list? Not > everything that was talked about, but the major discussion points at least. > That way it's there for future reference, and people who didn't read the > entire discussion thread can get a summary before they vote. As it sits now, > it doesn't really present all sides of the issue well... I agree — I actually was hoping to update the RFC post-discussion to reflect what had been discussed, but I've had a bit of a perfect storm of problems this week that have prevented me from putting any real time into PHP matters. I can have a look at revising the RFC on the weekend, but if you or someone else wanted to summarise the main "no" position and insert it before that, I'd have absolutely no objections. Thanks, Adam --- ## #64094 — Lester Caine — 2012-11-29T07:57:28+00:00 URL: https://externals.io/message/64065#64094 · In reply to: #64090 Kris Craig wrote: > Either way, our common goal here is to get people to stop using ext/mysql now so > that we can trash it when the time comes. And as far as that goes, I think that > what happened with magic_quotes and Drupal is a perfect example of how > deprecation can effectively push devs to act when docs and "get the word out" > campaigns aren't enough. The use of 'Drupal' as an example is totally spurious here. `E_DEPRECATED` and `E_STRICT` upgrades to any framework needed to be managed and in many cases switching to later versions of PHP are ALWAYS linked to a new major version of the framework. It is because the older versions are still expected to work with older versions of PHP. I'm sure you will find today that most of these frameworks ACTUALLY disable `E_STRICT` and `E_DEPRECATED` by default so that they continue to run on on the range of PHP versions they were originally designed for? Making something that only works with PHP5.4 is simply not practical when the bulk of the hosting is still on PHP5.2! Drupal is not the only framework that has to support it live user base. This does return to something that people have got irritated with me before but has been highlighted again here. Extensions are NOT core to PHP and most distributions including the windows ones do not provide a single executable for PHP but rather allow one to select what is loaded manually. I think it is quite obvious that even if `E_DEPRECATED` gets added to an 'official' distribution of mysql in PHP, that this will get stripped back out by the distributions as inappropriate in modular distributions? So why create the agro in the first place? It IS the education that is missing ... but equally there ARE still valid reasons to use mysql just as there are for the list of other retired extensions listed here. Creating even more problems for users is simply counter productive when there is STILL a need to educate users as to how to make their PHP5.2 code 'work' with PHP5.3/4 so that ISP's ARE in a position TO upgrade at all! And I speak with my 'hosting' hat on here. -- 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 --- ## #64095 — Pierre Joye — 2012-11-29T08:27:39+00:00 URL: https://externals.io/message/64065#64095 · In reply to: #64091 hi Anthony, As you are (relatively) new in php.net, let keep the history in mind while comparing things. > Actually, it is very much within the scope of this discussion. > > Case in point, take a look at 5.3.0. The following extensions were moved to > PECL: > > > - ext/dbase > - ext/fbsql > - ext/fdf > - ext/ncurses > - ext/mhash (BC layer is now entirely within ext/hash) > - ext/ming > - ext/msql > - ext/sybase > > Now you could make the argument that they weren't as used as ext/mysql. But > they were removed from core without raising `E_DEPRECATED` first. Back to this time, there was no release RFC and it was a simple +/- 1 vote to get an extension out of the distributions. So it is hardly comparable to the current situation. > So there definitely is precedent to remove without deprecating first. So > it's completely within the realm of discussion here. No there is not one, not since the RFC introduction. Removing extension in minor (x.y+1 or x.y.z+1) is not allowed. > The problem with this statement is that you're indicating something that > didn't happen. "get the word out" campaigns have not happened on an > official level for ext/mysql. The wording in the docs is light at best. > There has been very little effort from the side of the project to say "get > off it now". And that's what some of us have against this concept of > raising `E_DEPRECATED` in 5.5 (or possibly ever)... With the risk to repeat myself here (like 99.99% of the posts in this thread), almost all major projects out there have zero issue with the deprecation flag. They even agree to get it as it will help to convince their developers and users to update their code and setups. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #64096 — Pierre Joye — 2012-11-29T09:19:37+00:00 URL: https://externals.io/message/64065#64096 hi Alan! > .. annoying top posting... Why do you top post too then? :) > This is getting close to a good solution. > > ini option mysql_is_deprecated - can not be set in .ini/htaccess etc, only > by `ini_set()` - so hosters/distros can not fix it... Are you asking to add an option to do exactly the same than the error reporting option does? > Normally added just before mysql_connect... > > ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE"); eror_reporting(...); > mysql_connect(......) > Solves: > - Users will get warnings on upgrading - it can not be hidden by > hosters/distros etc. > - Users can easily disable the warning, however they will be explicitly > aware of the problem. Warning on install, on connect and in the doc is not enough? :) And once it is on pecl, we have the superseded/deprecated flag too there. It won't help for distros but distros will follow app leads, as usual. The only reason why distros still provide ext/mysql by default is because the apps require it by default. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #64100 — johannes@schlueters.de — 2012-11-29T11:39:50+00:00 URL: https://externals.io/message/64065#64100 · In reply to: #64091 > Case in point, take a look at 5.3.0. The following extensions were moved to > PECL: > > > - ext/dbase > - ext/fbsql > - ext/fdf > - ext/ncurses > - ext/mhash (BC layer is now entirely within ext/hash) > - ext/ming > - ext/msql > - ext/sybase > > > Now you could make the argument that they weren't as used as ext/mysql. But > they were removed from core without raising `E_DEPRECATED` first. There is another argument: Those aren't deprecated. They were just moved. Aside from mhash it is still fine to use those, we simply don't bundle them anymore. For mhash there is an equivalent replacement in the distribution. With ext/mysql it is about "don't use this anymore. Use mysqli or such" johannes --- ## #64104 — Jan Ehrhardt — 2012-11-29T15:46:31+00:00 URL: https://externals.io/message/64065#64104 · In reply to: #64083 Kris Craig in php.internals (Wed, 28 Nov 2012 12:33:55 -0800): >We also know that `E_DEPRECATED` works when other approaches do not. I would >point you all to the famous example of Drupal 7, which would break >completely due to a flurry of `E_DEPRECATED` warnings (if display_errors was >set to on) being triggered as of 5.3 due to their continued use of >magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some >time later, the code was fixed so that it no longer used those out-dated >functions. http://drupal.org/community-initiatives/drupal-core Drupal 8 will not be released before August 2013. Maybe in the current core the `E_DEPRECATED` warnings are gone, but certainly not in many of the modules. People are still switching to Drupal7. And Drupal7 throws the watchdog full with `E_DEPRECATED` warnings when it is running onder PHP5.4. The views module has issues with PHP 5.4, but some modules even let Drupal7 under PHP5.4 crash completely: http://drupal.org/node/1831402 If `E_DEPRECATED` stays in ext/mysql even after it has moved to PECL, the result will be that more and more people turn `E_DEPRECATED` warnings off. Jan --- Next page: https://externals.io/message/64065.md?page=2