Earlier this month, the PHP developer team moved to start soft deprecating the mysql.so extension via documentation, with a intent to fully E_DEPRECATED in a later release. [1] Therefore, I thought it would be appropriate to start a small discussion as to how this should be handled.
At the current moment, MediaWiki is still using these functions in its DatabaseMysql class. Being a new contributor to MW this came across as odd as to why no MySQLi implementation was available, so I went ahead and created one [2] (Patch [3]). Right now it's just another $wgDBtype, how it should really be integrated is what I want to discuss. Should any implementation (not necessarily mine) using MySQLi just be another DBType in the installer perhaps? (Most software I've seen goes this route) Also, at what point (time or event) do we do away with mysql function support? Also, are there any performance regressions with MySQLi that we should be aware about?
[1]: http://marc.info/?l=php-internals&m=131031747409271&w=http://marc.info/?l=php-internals&m=131031747409271&w=2 2 http://marc.info/?l=php-internals&m=131031747409271&w=2 [2]: https://github.com/johnduhart/mediawiki-trunk-phase3/commit/552a90f5142bb108... [3]: https://gist.github.com/1115789
On 7/30/2011 1:07 PM, John Du Hart wrote:
Earlier this month, the PHP developer team moved to start soft deprecating the mysql.so extension via documentation, with a intent to fully E_DEPRECATED in a later release. [1] Therefore, I thought it would be appropriate to start a small discussion as to how this should be handled.
At the current moment, MediaWiki is still using these functions in its DatabaseMysql class. Being a new contributor to MW this came across as odd as to why no MySQLi implementation was available, so I went ahead and created one [2] (Patch [3]). Right now it's just another $wgDBtype, how it should really be integrated is what I want to discuss. Should any implementation (not necessarily mine) using MySQLi just be another DBType in the installer perhaps? (Most software I've seen goes this route) Also, at what point (time or event) do we do away with mysql function support? Also, are there any performance regressions with MySQLi that we should be aware about?
2http://marc.info/?l=php-internals&m=131031747409271&w=2 [2]: https://github.com/johnduhart/mediawiki-trunk-phase3/commit/552a90f5142bb108... [3]: https://gist.github.com/1115789
I'd like to see PDO support[1] in addition to MySQLi, reasons being is that: a) PDO is a common interface for all types of databases (supports MySQL, Postgres, SQLite, and bunch of others) as long as the appropriate drivers are installed, which would allow us to cut down on the amount of code in the Database* classes considerably (to the point where most of the methods could probably be implemented in DatabaseBase without any issue) b) PDO ships with PHP 5.1+ (and MediaWiki requres 5.2+), although it seems that only the SQLite driver is installed by default. Haven't checked packages to see what the various distros all enable yet. c) Both PDO and MySQLi support "prepared" statements, which could let us introduce a form of statement cache so that if we need to execute the same query multiple times except with different parameters, there is less overhead involved since the statement is already prepared and just needs the data values to use. Another bonus of prepared statements is that it properly escapes everything according to whatever database engine you happen to be using when you substitute in parameters. d) Supporting both PDO and MySQLi will allow MediaWiki to be installed in more server configurations, as some hosts may have one enabled but not the other.
I think that they should be considered separate db types as far as the installer is concerned so that users can choose between the one they wish to use (we can of course mark the old mysql one as "not recommended" to coerce users into picking one of the other two if they have them available for use).
c) Both PDO and MySQLi support "prepared" statements, which could let us introduce a form of statement cache so that if we need to execute the same query multiple times except with different parameters, there is less overhead involved since the statement is already prepared and just needs the data values to use.
That statement cache needs persistent connections, which are somewhat expensive. Otherwise you're doing two roundtrips instead of one, and there's not much performance win anyway.
Another bonus of prepared statements is that it properly escapes everything according to whatever database engine you happen to be using when you substitute in parameters.
I don't think that has been an issue lately.
Domas
John Du Hart wrote:
Earlier this month, the PHP developer team moved to start soft deprecating the mysql.so extension via documentation, with a intent to fully E_DEPRECATED in a later release. [1] Therefore, I thought it would be appropriate to start a small discussion as to how this should be handled.
The goal is to recommend alternatives that would make new code use the other options, due to security issues with most mysql code. Given that mediawiki uses a wrapper which escapes the variables, I see no hurry in adding a mysqli implementation.
At the current moment, MediaWiki is still using these functions in its DatabaseMysql class. Being a new contributor to MW this came across as odd as to why no MySQLi implementation was available, so I went ahead and created one [2] (Patch [3]).
There was no need for it.
Right now it's just another $wgDBtype, how it should really be integrated is what I want to discuss. Should any implementation (not necessarily mine) using MySQLi just be another DBType in the installer perhaps? (Most software I've seen goes this route)
Yes. Having it as another $wgDBtype is the right way (perhaps with a common parent for both mysql classes?).
Also, at what point (time or event) do we do away with mysql function support? Also, are there any performance regressions with MySQLi that we should be aware about?
Probably, some time after mysql is removed from php, which could never happen.
wikitech-l@lists.wikimedia.org