Last modified: 2013-10-23 16:23:02 UTC
So we get nice things like subqueries, which using them now was somewhat dependant on what the cluster was running. MySQL 5 has been production release since October 2005 [1], I think we've been supporting it long enough. I can't imagine too many people are still running it...? [1] http://en.wikipedia.org/wiki/MySQL#Product_history
Note, I'm not suggesting to actively break back compat (is there any way we could?)? Does anyone even actually test on mysql4 now after the last mysql boxen have gone from WMF?
Using subqueries would pretty actively break back compat. :) I've no objection to this...
(In reply to comment #2) > Using subqueries would pretty actively break back compat. :) > > I've no objection to this... I was meaning going actively out of our way to break it. But this is slightly pointless, and probably just ignore it completely But yeah, it's not like we're breaking stuff for a recent high use version of it. Maybe something just to explicitly change for 1.19, and going forward Probably some cleanup work to remove some of the mysql 4 related globals and such Be nice to clear it all out Thinks like: $wgDBmysql4, $wgDBmysql5... And then 4 other usages in MysqlInstaller
r104045 kills $wgDBmysql4 r104046 kills some mysql 4 related code from the installer r104047 Kill mysql4 code from DatabaseMysql, bumps minimum mysql version in the installer TODO: * Kill 'config-charset-mysql4' ? * Kill $existingSchema = 'mysql4'; ? *
> MySQL 5 has been production release since October 2005 [1], I think we've been > supporting it long enough. > I can't imagine too many people are still running it...? We were running mysql 4 until 2009 or so. $wgDBmysql4 is always true "for compatibility with extensions that might be checking". Seems $wgDBmysql5 should follow the same fate. Anyway $wgDBmysql5 does a useful task. Suddenly sending SET NAMES utf8 to everybody would break utf8-in-latin1 installs (beginning with WMF servers). A second reason to avoid subqueries was that 'they were inefficient'. Which ones did you want to add? If we don't have a direct gain from dropping support, I'd keep it in.
(In reply to comment #5) > > MySQL 5 has been production release since October 2005 [1], I think we've been > > supporting it long enough. > > I can't imagine too many people are still running it...? > > We were running mysql 4 until 2009 or so. > We only got rid of it it on the live WMF sites in the last few months...
I wouldn't run to remove it, then.
MediaWiki 1.19 and above do not support MySQL 4 and below. Is the message 'config-charset-mysql' the only reason this is not RESOLVED FIXED?
We're already requiring >= 5.0.2 public $minimumVersion = '5.0.2'; Back in 16:27, 23 November 2011 I made this 5.0.0 There's also another 7 usages in comments/commented code which should potentially be addressed and/or bugs filed for them. This could then be used as a tracking bug for these issues There are 4 installed related messages that mention MySQL 4.X, which I believe is suggestionable that MySQL 4.X can actually be used. This really isn't the case, is misleading and should be removed MySQL 4.0 back-compat isn't needed 'config-charset-mysql5-binary' => 'MySQL 4.1/5.0 binary', 'config-charset-mysql5' => 'MySQL 4.1/5.0 UTF-8', 'config-charset-mysql4' => 'MySQL 4.0 backwards-compatible UTF-8', 'config-charset-help' => "'''Warning:''' If you use '''backwards-compatible UTF-8''' on MySQL 4.1+, and subsequently back up the database with <code>mysqldump</code>, it may destroy all non-ASCII characters, irreversibly corrupting your backups! In '''binary mode''', MediaWiki stores UTF-8 text to the database in binary fields. This is more efficient than MySQL's UTF-8 mode, and allows you to use the full range of Unicode characters. In '''UTF-8 mode''', MySQL will know what character set your data is in, and can present and convert it appropriately, but it will not let you store characters above the [//en.wikipedia.org/wiki/Mapping_of_Unicode_character_planes Basic Multilingual Plane].",
