rfc:mysql_deprecation
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:mysql_deprecation [2012/11/13 03:06] – Bump version number. aharvey | rfc:mysql_deprecation [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Request for Comments: ext/mysql deprecation ====== | ====== Request for Comments: ext/mysql deprecation ====== | ||
- | * Version: 1.1 | + | * Version: 1.2.1 |
- | * Date: 2012-11-12 | + | * Date: 2012-12-10 |
* Author: Adam Harvey < | * Author: Adam Harvey < | ||
- | * Status: | + | * Status: |
* First Published at: https:// | * First Published at: https:// | ||
* Trivial patch: http:// | * Trivial patch: http:// | ||
+ | * Original discussion: http:// | ||
+ | * Voting discussion: http:// | ||
This RFC proposes to generate E_DEPRECATED errors when connecting to a MySQL database with the ext/mysql API. | This RFC proposes to generate E_DEPRECATED errors when connecting to a MySQL database with the ext/mysql API. | ||
+ | |||
+ | ===== Voting ====== | ||
+ | |||
+ | Please note that there are two questions below: please vote on both if possible. The first controls the direct result of this RFC, while the second is to provide guidance should the RFC be rejected. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | There are four options available for the next question: | ||
+ | |||
+ | If the vote to make ext/mysql generate E_DEPRECATED errors is unsuccessful, | ||
+ | |||
+ | * **(a)** Enhance the manual text to make the soft deprecation clearer, and generate E_DEPRECATED notices in PHP 5.6. | ||
+ | * **(b)** Enhance the manual text to make the soft deprecation clearer, but take no further action in terms of E_DEPRECATED for the forseeable future. | ||
+ | * **%%(c)%%** Remove the warnings from the manual and undeprecate ext/mysql entirely. | ||
+ | * **(d)** Do nothing. | ||
+ | |||
+ | <doodle title=" | ||
+ | > | ||
+ | * (a) | ||
+ | * (b) | ||
+ | * (c) | ||
+ | * (d) | ||
+ | </ | ||
===== Background ===== | ===== Background ===== | ||
Line 21: | Line 49: | ||
[[http:// | [[http:// | ||
+ | |||
+ | The proposed wording of the deprecation message is: | ||
+ | |||
+ | > The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead | ||
===== Why? ===== | ===== Why? ===== | ||
Line 46: | Line 78: | ||
None of those reasons have gone away. | None of those reasons have gone away. | ||
- | ===== Issues ===== | + | Ulf Wendel has also written [[http:// |
- | I don't believe either | + | Furthermore, |
+ | |||
+ | > ext/mysql is hard to maintain code. It is not not getting new features. Keeping it up to date for working with new versions | ||
+ | |||
+ | ===== Why Not? (Other Options) ===== | ||
+ | |||
+ | Arguments against raised on Internals include the following: | ||
+ | |||
+ | ==== Documentation ==== | ||
+ | |||
+ | The current warning in the manual is very weakly worded once you get past the red warning box. That could be beefed up considerably | ||
+ | |||
+ | ==== Large Existing Codebase (Too Soon) ==== | ||
+ | |||
+ | There is also a huge amount of code out there that relies on ext/mysql. At the very least, a compatibility library will need to be developed if ext/mysql is to ever be unbundled. | ||
+ | |||
+ | As Anthony Ferrara said on why he believes it's too soon: | ||
+ | |||
+ | > My standpoint would be not to add E_DEPRECATED notices in 5.5... It's simply used too much to start loudly complaining about it. Instead, what I would suggest is the following: | ||
+ | > | ||
+ | > 1. Officially deprecate it now. Right now, on the docs it says " | ||
+ | > 2. The next release (5.6 or 6) would add deprecation errors to the code. | ||
+ | > 3. The next release (5.7 or 6 or 6.1, etc) would then remove the extension entirely. | ||
+ | > | ||
+ | > That way there's a significant roadmap towards deprecation, | ||
+ | |||
+ | Additionally, | ||
+ | |||
+ | ==== Frameworks ==== | ||
+ | |||
+ | Related to the above, some frameworks and commonly used products still require ext/mysql without any option to use MySQLi or PDO: notable examples include WordPress and Plesk. | ||
==== Tutorials ==== | ==== Tutorials ==== | ||
Line 54: | Line 116: | ||
There are thousands of tutorials out there that teach users PHP using ext/mysql. Many of these tutorials also teach other outdated practices, such as magic quotes, improper (or no) escaping of user input and use of register globals, but undoubtedly some are also still of value. Removing ext/mysql in future will make these tutorials at best useless, and at worst, impediments to PHP takeup. | There are thousands of tutorials out there that teach users PHP using ext/mysql. Many of these tutorials also teach other outdated practices, such as magic quotes, improper (or no) escaping of user input and use of register globals, but undoubtedly some are also still of value. Removing ext/mysql in future will make these tutorials at best useless, and at worst, impediments to PHP takeup. | ||
- | ==== Large Existing Codebase | + | ==== We Could Move It To PECL Now ==== |
- | There is also a huge amount of code out there that relies | + | Another argument is that ext/mysql could be unbundled in PHP 5.5 and moved straight to PECL. |
+ | |||
+ | ==== E_DEPRECATED Is Inappropriate ==== | ||
+ | |||
+ | Concerns were raised that the normal deprecation process isn't appropriate for such a widely used extension. Again, quoting Anthony Ferrara: | ||
+ | |||
+ | > There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal " | ||
+ | > | ||
+ | > Look at what was deprecated and removed so far. We deprecated register globals and magic quotes. The process worked | ||
+ | > | ||
+ | > 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/ | ||
+ | > | ||
+ | > What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, officially deprecate it in the docs. Then start a PR campaign | ||
+ | |||
+ | ==== It's Not Broken ==== | ||
+ | |||
+ | Quoting Ángel González: | ||
+ | |||
+ | > 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. | ||
+ | |||
+ | ==== Hosting Providers Don't Provide Alternatives ==== | ||
+ | |||
+ | No numbers were provided for this, but an additional concern is that hosting providers almost universally provide ext/mysql, but the deployment state of MySQLi and PDO is less certain. | ||
===== Possible Future Action ===== | ===== Possible Future Action ===== | ||
Line 66: | Line 152: | ||
==== Converting to MySQLi or PDO ==== | ==== Converting to MySQLi or PDO ==== | ||
- | * https://wikis.oracle.com/display/ | + | * http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers |
==== Suppressing deprecation warnings ==== | ==== Suppressing deprecation warnings ==== | ||
Line 78: | Line 164: | ||
===== Changelog ===== | ===== Changelog ===== | ||
+ | * 1.2.1 (2012-12-10): | ||
+ | * 1.2 (2012-12-07): | ||
+ | * 1.1.2 (2012-11-28): | ||
+ | * 1.1.1 (2012-11-19): | ||
* 1.1 (2012-11-13): | * 1.1 (2012-11-13): | ||
* 1.0 (2012-11-12): | * 1.0 (2012-11-12): |
rfc/mysql_deprecation.1352776003.txt.gz · Last modified: 2017/09/22 13:28 (external edit)